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SUMMARY 


Mistakes  in  software  programs  are  isolated  and  repaired  by  a  process 
called  "debugging."  Programmers  can  use  software  debugging  tools  to  help 
them  find  and  fix  errors  in  their  code  more  rapidly  than  debugging  by  hand. 
Less  than  one-third  of  programmers,  however,  use  debugging  tools. 
Programmers  may  not  be  using  them  because  the  tools  do  not  allow  them  to 
use  their  standard  techniques.  The  present  research  investigated  the 
techniques  used  by  programmers  as  they  debug  their  own  code.  By  learning 
how  programmers  typically  debug  code,  software  debugging  tools  can  be 
designed  to  take  advantage  of  programmers'  established  modes  of  operation. 

Twelve  programmers  served  in  this  experiment.  They  completed  a 
questionnaire  and  were  given  three  programming  tasks  to  code.  The 
subjects'  coded  data  were  examined  to  find  the  errors  that  had  to  be 
debugged.  Each  error  was  identified  and  the  technique  the  subject  used  to 
find  the  error  was  noted. 

Overall,  the  programmers  used  the  code,  the  output,  debug  print 
statements,  and  hand-simulation  to  find  their  bugs.  The  programmers' 
debugging  techniques,  insertion  of  debug  print  statements  and 
hand-simulation  are  supported  by  most  debuggers;  and  the  results  would  have 
been  more  accurate,  in  that  the  system  would  not  have  overlooked  any  line 
of  code.  None  of  the  subjects  in  this  experiment,  however,  used  the 
debugger. 

The  results  of  this  experiment  imply  that  debuggers  would  be  used  more 
frequently  if  they  were  easier  to  learn.  Because  the  programmers' 
functional  needs  are  being  met,  designers  should  now  concentrate  on  the 
presentation  of  the  debugger,  including  interface  design,  documentation, 
and  marketing. 
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PREFACE 


The  general  objective  of  the  research  described  in  this  report  was  to 
analyze  methods  used  by  professional  programmers  in  debugging  their  own 
code.  The  results  were  used  to  evaluate  the  functional  correspondence 
between  software  debugging  tools  and  current  debugging  methods. 

This  effort  supports  the  Training  Technology  objective  of  the  Air  Force 
Human  Resources  Laboratory  (AFHRL)  Research  and  Technology  Plan  by 
identifying  and  demonstrating  cost-effective  ways  of  developing  and 
maintaining  new  skills. 

This  work  was  accomplished  at  the  Air  Force  Human  Resources 
Laboratory's  Operations  Training  Division  (AFHRL/OT)  and  performed  by 
Captain  Pamela  M.  Merrick,  Principal  Invesigator,  under  Work  Unit 
1123-05-01,  In-House  Research  and  Development  Support.  This  work  would  not 
have  been  possible  without  the  oustanding  support  of  2Lt  Paul  Weiss  and 
2Lt  Joe  Drbohlav  from  the  82  Flying  Training  Wing,  who  were  instrumental  in 
preparing  the  protocol  data  for  analysis.  The  author  also  wishes  to  thank 
Dr.  Peter  M.  Crane,  AFHRL/OT,  who  provided  invaluable  critiques  and 
comments  throughout  the  duration  of  this  effort. 
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DEBUGGING  TECHNIQUES  USED  BY  EXPERIENCED  PROGRAMMERS 
TO  DEBUG  THEIR  OWN  CODE 

I .  INTRODUCTION 

Software  programs  seldom  work  correctly  when  first  coded.  If  a  program 
does  not  meet  its  specifications  after  havir  een  coded,  mistakes  are 
isolated  and  repaired  by  debugging.  Debugging  is  generally  considered  to  be 
the  most  expensive  phase  of  software  production  (Sheil,  1981),  due  to  the 
extensive  testing  required  to  find  and  fix  all  errors.  Between  40 %  and  70% 
of  a  programmer's  time  is  spent  removing  "bugs"  (Seviora,  1987).  The  cost 
to  fix  a  mistake  increases  as  the  development  cycle  progresses.  At  Digital 
Equipment  Corporation,  it  has  been  estimated  (Harris,  1988)  that  if  software 
bugs  cost  $1  to  fix  before  coding,  the  relative  cost  to  fix  software  bugs 
is  $1.50  during  coding,  $10  before  field  testing,  $60  during  field  testing, 
and  $100  in  the  field.  Therefore,  debugging  code  early  in  the  programming 
process  minimizes  production  costs. 

Aside  from  the  costs  involved,  debugging  is  also  a  frustration  of 
creative  talents.  Once  a  programmer  has  coded  his  work,  he  wants  to  get  on 
to  the  next  problem;  so,  the  debugging  is  done  in  an  atmosphere  of 
impatience  (Brown  &  Sampson,  1973).  This  general  lack  of  enthusiasm  for 
debugging  is  heightened  when  a  programmer  has  to  debug  someone  else's  code 
(Seviora,  1987). 

Software  debugging  tools,  such  as  VAX  DEBUG  (Beander,  1983),  can  help 
programmers  find  and  fix  errors  in  their  code  more  rapidly  than  debugging  by 
hand.  However,  in  a  study  of  software  engineering  practices  in  30 
companies,  Zelkowitz,  Yeh,  Hamelt,  Gannon,  and  Basili  (1984)  found  that  only 
27%  of  the  programmers  used  any  kind  of  testing  tools.  Many  had  debuggers 
available,  but  were  not  using  them.  Simple  code  reading  was  the  preferred 
approach.  The  reasons  given  for  lack  of  use  ranged  from  "hard  to  learn"  to 
"not  very  useful."  It  is  possible  that  the  majority  of  programmers  do  not 
use  debugging  tools  because  the  tools  do  not  reflect  the  debugging 
techniques  they  most  typically  employ.  By  learning  how  expert  programmers 
typically  debug  code,  more  useful  software  tools  could  be  designed. 

Most  studies  on  debugging  practices  have  concentrated  on  novice 
programmers  and  fail  to  offer  guidance  in  developing  advanced  software 
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development  environments  (Curtis,  1986).  Shneiderman  (1986)  has  suggested 
that  the  design  of  testing  and  debugging  tools  would  benefit  from  human 
factors  studies  of  how  experienced  programmers  do  testing  and  debugging. 

Literature  Review 

Prior  Debugging  Studies 

Prior  research  on  debugging  falls  into  three  categories,  according  to 
who  is  being  studied:  novice  programmers,  novices  compared  to  experts,  and 
expert  programmers  only. 

Kessler  and  Anderson  (1986)  investigated  true  novices  who  had  no 
previous  programming  experience.  After  attending  a  one-day  LISP  tutorial, 
the  novices  attempted  to  debug  12  one-line  LISP  functions.  The  protocol 
data  collected  showed  that  six  of  the  seven  subjects  used  the  same  four-step 
debugging  strategy  for  all  problems.  First  they  tried  to  understand  what 
the  code  was  doing.  Next,  they  ran  the  code  to  detect  the  error.  Then  they 
searched  for  the  piece  of  code  responsible  for  the  error.  Finally,  they 
corrected  the  bug.  The  fourth  step,  bug  repair,  was  found  to  be  extremely 
difficult  and  independent  of  the  first  three  steps. 

Carver  and  Klahr  (1986)  broke  the  novice  debugging  strategy  into  more 
detailed  steps  in  an  effort  to  develop  debugging  instruction.  Their 
strategy  was  as  follows: 

1.  Test  the  program  by  running  it. 

2.  Compare  actual  output  to  desired  output  and  evaluate  the 
differences. 

3.  Describe  any  discrepancies. 

A.  Propose  possible  bugs  and  ways  to  find  them. 

5.  Look  for  information  about  the  program  structure's  data 
representation. 

6.  Specify  each  bug's  likely  location  within  the  structure. 

7.  Search  and  find  the  bugs  in  the  code. 

8.  Interpret  each  command  and  check  the  command's  effect. 

9.  Change  code  by  replacing  bad  code  with  the  appropriate 
correction. 

10.  Begin  again  by  running  the  program  to  test  it. 
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Carver  and  Riainger  (1987)  £ound  that  apeed  and  efficiency  improved  vhen 
children  were  taught  hov  to  narrow  the  search  for  bugs  using  this  strategy. 

Spohrer  and  Solovay  (1986)  examined  the  types  of  bugs  introduced  by 
novices,  as  opposed  to  novice  debugging  strategies.  They  analyzed  the  first 
syntactically  correct  versions  of  10  programs  submitted  by  61  students 
during  a  semester-long  course.  Bug  type  and  frequency  were  examined.  They 
observed  that  20X  of  the  bug  types  accounted  for  55X  of  the  errors.  Based 
on  analysis  of  the  most  common  bug  types,  Spohrer  and  Solovay  concluded  that 
novices  had  difficulties  with  the  following  seven  itemst  deciding 
appropriate  boundary  points,  detecting  dependencies  that  affect  nesting, 
negation  of  complex  logic,  dropping  the  final  digit  on  constants  with 
repeating  tail  digits,  determining  the  precedence  of  operators,  assuming 
incorrect  ways  to  calculate  quantities  from  specification  misinterpretation, 
and  interference  of  similar  numbers  with  incorrect  answers. 

Several  studies  have  been  conducted  comparing  novice  and  expert 
programmers'  debugging  techniques.  Jeffries  (1982)  had  six  experts  and  four 
novices  debug  tvo  Pascal  programs  that  contained  several  bugs  each.  Vessey 
(1985)  asked  eight  novices  and  eight  experts  to  debug  a  COBOL  program  with 
one  error  in  it.  Gugerty  and  Olson  (1986)  ran  tvo  groups  of  subjects.  The 
first  group  consisted  of  eighteen  experts  and  six  novices  who  debugged  three 
LOGO  programs  with  one  bug  in  each  program.  Ten  novices  and  ten  experts 
comprised  the  second  group  for  debugging  a  Pascal  program  containing  one 
error.  Finally,  Nanja  and  Cook  (1987)  used  a  Pascal  bubble  sort  program 
with  six  errors  to  test  six  novices,  six  Intermediates,  and  six  experts. 

All  five  of  these  studies  produced  similar  results  vhen  comparing  expert 
to  novice  debugging  performance.  The  experts  started  by  reading  the  code  in 
the  order  that  it  would  be  executed.  They  spent  a  fair  amount  of  time 
gaining  a  high-level  understanding  of  hov  the  program  functioned.  Once  they 
understood  the  program  and  what  it  was  supposed  to  do,  they  applied  this 
knowledge  to  place  the  error  in  context.  Experts  then  quickly  located  the 
bug  and  often  corrected  it  properly  the  first  time,  and  never  introduced  new 
bugs.  Experts  found  more  bugs  and  found  them  faster.  Nanja  and  Cook's 
experts  (1987)  were  the  only  ones  who  used  the  interactive  debugger.  In  all 
five  studies,  the  novices  used  a  much  less  organized  approach.  Pirst,  they 
read  the  code  from  top  to  bottom,  regardless  of  actual  execution  order. 
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They  then  immediately  jumped  in  and  tried  to  find  the  bugs.  Due  to  lack,  of 
program  comprehension,  their  initial  hypotheses  were  inferior  and  made  it 
hard  to  find  relevant  parts  of  the  code.  Without  an  overall  understanding, 
it  took  them  longer  to  confirm  or  reject  error  corrections.  Novices  often 
added  new  bugs  by  forgetting  to  undo  incorrect  fixes. 

Holt,  Boehm-Davis,  and  Schultz  (1987)  also  compared  experts  and  novices, 
but  focused  on  the  way  a  computer  program  is  represented  cognitively  and  how 
that  representation  is  used.  The  experts'  mental  models  were  significantly 
affected  by  the  difficulty  of  the  module;  that  is,  the  more  difficult  the 
program,  the  more  elaborate  the  mental  model.  The  structure  and  content  of 
the  program,  however,  did  not  affect  the  experts'  mental  models.  The 
novices,  on  the  other  hand,  were  not  affected  by  module  difficulty,  but  were 
affected  by  program  structure.  This  finding  implies  experts  are  better  at 
abstracting  the  code  and  less  influenced  by  the  superficial  or  peripheral 
aspects  of  the  code.  This  ability  to  abstract  code  was  crucial  in  the 
programmers'  performance.  The  researchers  also  found  the  number  of 
languages  and  operating  systems  used,  as  well  as  the  number  of  programs 
written,  to  be  a  better  indicator  of  an  expert  than  years  of  schooling  or 
professional  programming. 

Three  studies  examined  expert  programmers  only.  Gould  and  Drongowski 
(1974)  and  Gould  (1975)  explored  the  techniques  used  by  Fortran  programmers 
to  find  bugs  in  12  programs,  each  containing  a  one-line  bug.  The  bugs  were 
categorized  as  array  indexing  bugs,  iteration  loop  bugs,  and  assignment 
statement  bugs.  In  both  studies,  it  was  found  that  assignment  statement 
bugs  were  three  times  harder  to  find  than  the  other  two  types  and  debugging 
was  three  times  more  efficient  on  programs  that  had  been  previously  debugged 
with  different  bugs.  In  Gould's  (1975)  study,  an  interactive  debugger  was 
also  made  available  to  the  programmers;  however,  they  rarely  made  use  of  it. 
The  general  strategy  used  was  to  select  a  debugging  tactic  and  search  for 
something  suspicious.  After  a  clue  was  found,  a  hypothesis  about  the  bug 
was  generated  in  testable  terms  from  previously  acquired  knowledge.  If  the 
hypothesis  was  correct,  the  bug  had  been  found.  Otherwise,  a  new  clue  was 
identified  and  thr'  cycle  repeated.  Programmers  tended  to  ease  into 
debugging,  Gould  also  found.  First  they  eliminated  all  syntactic  bugs,  then 
grammatical  bugs  not  detected  by  the  compiler,  and  finally  the  substantive 
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bugs.  Also,  they  avoided  difficult  sections  of  the  code  until  the  rest  of 
the  code  had  been  eliminated. 

Guidon,  Krasner,  and  Curtis  (1987)  studied  breakdowns  that  occur  while 
expert  programmers  design  complex  software.  They  used  protocol  data 
collected  while  subjects  spent  2  hours  designing  logic  for  the  Sl-lift 
problem.  During  the  design  process,  the  programmers  were  found  to  place 
great  emphasis  on  using  mental  simulations  to  understand  and  elaborate  on 
the  requirements. 

Breakdowns  occurred  for  several  reasons.  Some  subjects  lacked 
specialized  knowledge  about  design  schemes  that  could  be  instantiated.  Some 
subjects  lacked  knowledge  about  design  process  goals  and  alternatives  to 
guide  them  in  the  amount  of  effort  to  spend  on  different  activities.  Poor 
prioritization  of  issues  and  constraints  led  to  poor  selection  from 
alternative  solutions.  Subjects  had  difficulty  considering  all  the  stated 
or  inferred  constraints  in  refining  their  solutions,  due  to  short-term 
memory  capacity.  Subjects  had  difficulty  performing  mental  simulations  with 
many  steps  or  many  test  cases,  again  due  to  cognitive  limitations.  Subjects 
had  difficulty  keeping  track  and  returning  to  postponed  sub-problems. 
Finally,  it  was  difficult  for  subjects  to  expand  and  merge  their  partial 
solutions  into  a  complete  solution. 

The  Debugging  Process 

Based  on  these  empirical  studies  and  personal  debugging  experience,  many 
authors  have  tried  to  describe  the  process  of  debugging.  Knoke  (1988) 
divided  the  debugging  process  into  four  separate  steps:  testing, 
stabilization,  localization,  and  correction.  During  the  testing  phase,  a 
wide  range  of  input  values  is  used  to  force  execution  of  all  program 
branches.  The  program's  capabilities  are  tested,  starting  with  normal 
values  and  then  proceeding  to  boundary  conditions  and  special  cases.  Any 
anomaly  indicates  a  possible  bug.  The  programmer  must  rely  on  his  knowledge 
of  what  to  check  and  how  to  analyze  the  resulting  output.  The  program  must 
then  be  stabilized  so  that  specific  bugs  can  be  generated  at  will.  Tne 
programmer  needs  to  be  in  control  of  the  conditions  which  cause  the  bug. 

The  bug  must  then  be  isolated  to  a  specific  variable  or  segment  of  code. 

This  localization  can  be  done  any  of  three  ways.  The  programmer  can 
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single-step  through  the  subject  code  until  abnormal  behavior  is  noted.  A 
trace  history  of  the  executed  code  may  be  examined,  or  the  programmer  can 
hypothesize  and  modify  code  to  test  the  hypothesis  validity.  The  bug  must 
then  be  corrected.  After  correction,  the  programmer  must  begin  again  with 
testing.  This  is  done  to  make  sure  the  edit  achieves  the  intended  purpose 
and  has  no  side  effects. 

Seviora  (1987)  pointed  out  that  programmers  usually  combine  Knoke's 
method  with  a  problem  analysis  approach.  The  main  emphasis  in  the  problem 
analysis  approach  is  to  eliminate  discrepancies  between  the  specification 
(what  the  program  should  do)  and  the  source  code  (what  the  program  actually 
does).  To  do  this,  the  programmer  relies  on  his  knowledge  of  program 
constructs  to  understand  what  the  code  does  and  how  its  parts  interact. 

Several  authors  have  suggested  that  one  aid  to  understanding  is  to 
reduce  the  amount  of  detail  by  extracting  only  relevant  information.  Veiser 
(1982)  ascertained  that  programmers  mentally  divide  their  code  into 
functional  sections  when  debugging.  They  break  apart  large  programs  into 
smaller  coherent  pieces,  which  are  not  necessarily  contiguous  parts  of  the 
text.  Lukey  (1980)  also  found  that  programmers  segment  programs  into  chunks 
of  code  that  form  useful  units  of  analysis.  The  segments  are  used  to 
identify  pieces  of  code  that  are  likely  to  be  bugged  and  eliminate  portions 
of  the  program  that  seem  to  be  running  correctly.  One  method  used  to 
identify  the  bad  code  is  backtracing.  A  path  is  traced  back  through  the 
immediately  preceding  assertions  related  to  the  discrepancy  (Lukey,  1980). 

By  working  backwards  from  the  symptoms,  bugs  are  often  easier  to  locate. 

Both  Gould  (1975)  and  Lukey  (1980)  noted  Instances  of  programmers  working 
backwards  from  an  error's  appearance  to  locate  its  source. 

Rasmussen  (1986)  found  that  programmers  also  use  prior  debugging 
experience  to  recall  previous  bugs  that  caused  symptoms  similiar  to  the 
current  one.  In  fact,  much  of  debugging  skill  is  learned  through  the 
experience  of  writing  programs  and  getting  them  to  run  (Gugerty  &  Olson, 
1986).  The  more  experienced  programmer  has  a  larger  mental  library  of 
symptom  bug  associations.  Faced  with  less  familiar  situations,  programmers 
resort  to  casual  reasoning  directly  from  the  source  code  (Seviora,  1987). 
When  completely  clueless,  programmers  hand-simulate  the  execution  of  their 
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program  on  paper.  They  may  also  add  debug  print  statements  and  change 
program  statements  just  to  see  what  will  happen  (Rasmussen,  1981). 

Overview 

The  present  research  examines  debugging  strategies  used  by  experienced 
programmers  debugging  their  own  code.  By  thoroughly  studying  the  techniques 
programmers  employ,  perhaps  we  can  discover  why  software  debuggers  are  not 
more  widely  used.  The  research  focused  on  isolating  the  strategies  applied, 
so  that  future  debuggers  can  be  designed  around  the  methods  programmers 
already  use. 

The  technique  of  protocol  analysis  was  used  for  data  collection  and 
analysis.  Each  subject  was  asked  to  verbalize  his  thoughts  while 
programming  the  assigned  tasks.  The  protocol  data  were  coded  and  used  to 
isolate  the  errors  the  programmers  made.  The  analysis  attempted  to  discover 
the  techniques  used  to  correct  the  bugs. 

Six  different  classes  of  programming  errors  have  been  described  in  the 
programming  literature.  Brown  and  Sampson  (1973)  called  the  first  class  of 
errors  "appreciation  errors."  These  bugs  result  from  the  programmer's 
misinterpreting  a  specification  or  failing  to  read  it  thoroughly  before 
starting  work.  The  second  class  covers  lexical  and  syntactic  errors.  These 
include  violation  of  a  language's  grammar  rules,  typographical  errors  and 
incorrect  translation  of  an  algorithm  to  program  code.  Since  the  compiler 
usually  catches  these  errors,  they  are  usually  the  easiest  to  correct.  The 
next  two  classes  are  run-time  errors  called  "execution  errors"  and  "intent 
(logic)  errors"  (Knoke,  1988).  Mistakes  are  called  execution  errors  when  a 
program  terminates  abnormally  due  to  run-time  checks,  out-of-bounds,  etc. 
With  intent  errors,  the  program  runs,  but  it  produces  incorrect  results. 
These  can  be  caused  by  design  flaws  or  incomplete  comprehension  of  the 
problem.  The  final  classes  of  errors  are  integration  and  portability  errors 
(Knoke,  1988).  Integration  problems  will  not  appear  until  two  or  more 
modules  are  combined  to  form  a  program,  and  portability  bugs  show  up  when 
code  is  moved  from  one  machine  to  another. 

In  most  of  the  previous  debugging  studies,  programmers  debugged  code 
that  contained  a  predetermined  number  of  bugs.  The  bugs  were  carefully 
chosen  and  placed  in  the  code  by  the  experimenters.  In  doing  so,  the 
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experimenters  limited  the  bugs  to  one  or  two  error  classes.  The  number  of 
error  types  encountered  by  programmers  debugging  their  own  code,  on  the 
other  hand,  is  limited  only  by  the  programmer's  skill.  This  research  should 
therefore  be  able  to  cover  all  except  the  final  bug  classes  (integration  and 
portability) . 


Protocol  Analysis 

The  technique  of  protocol  analysis  was  used  to  examine  debugging 
strategies  employed  by  experienced  programmers.  Protocol  analysis  is 
ideally  suited  to  the  development  and  testing  of  theories  in  the  emerging 
computer  programming  domain  (Fisher,  1987).  In  protocol  analysis,  subjects 
are  asked  to  talk/think  aloud  as  they  solve  problems.  The  verbalizations 
are  then  used  to  track  the  cognitive  processes  used  to  perform  the  task. 

The  method  has  been  used  to  study  a  variety  of  complex  mental  tasks. 
Rasmussen  (1981)  used  protocol  analysis  to  invest  te  diagnostic  strategies 
used  by  technicians  to  find  faults  in  an  operational  process  plant  control. 
Blackman  (1988)  identified  the  mental  models  used  by  expert  fliers  with 
protocol  analysis,  for  use  in  flight  simulator  training.  Soloway  (1986) 
predicted  that  protocol  methodology  will  become  the  major  source  of  data  in 
studying  initial  aspects  of  programming  practices. 

Ericsson  and  Simon  (1984)  have  developed  a  set  of  procedures  and 
guidelines  for  collecting  and  analyzing  protocol  analysis  data.  The  use  of 
protocol  analyses  to  infer  cognitive  processes  is  based  on  theoretical 
assumptions  about  human  cognition.  The  major  assumption  is  that  the  same 
cognitive  processes  which  generate  other  recordable  responses  also  generate 
verbalizations  (Ericsson  &  Simon,  1984).  This  implies  that  information  can 
be  reported  only  if  it  is  attended  to.  New  information  and  immediate 
results  of  mental  operations  can  be  vocalized  directly.  Information  from 
long-term  memory,  however,  is  subject  to  memory  consolidation  over  time, 
selective  retrieval,  and  inferential  processing.  Therefore,  concurrent 
reports  (reports  given  during  problem  solving)  are  assumed  to  be  more 
accurate  and  complete  than  retrospective  reports  (reports  given  after 
problem  solving)  (Ryder,  Redding,  &  Beckschi,  1988). 

The  first  uses  of  verbal  data  in  research  were  criticized  as  being 
unreliable.  Some  have  argued  (Cooke  &  McDonald,  1986;  Nisbett  &  Wilson, 
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1977)  that  subjects  are  not  aware  of  relevant  information  during  experiments 
and  therefore  cannot  make  accurate  reports.  These  researchers  found  that 
people  sometimes  base  answers  on  inferences  about  what  they  think,  lathei. 
than  relying  on  memory.  Ericsson  and  Simon  (1984)  point  out  that  these 
studies  would  have  yielded  considerable  insight  had  better  probing  methods 
been  used.  The  validity  of  a  verbal  report  depends  greatly  upon  the 
questions  and/or  instructions  used  to  elicit  the  report.  Therefore; 
protocol  analysis  requires  careful  planning,  data  collection,  and  analysis 
to  maximize  the  likelihood  of  obtaining  reliable  information  (Ryder  et  al., 
1988). 

Another  criticism  of  verbal  data  has  been  that  the  cognitive  processes 
themselves  could  be  affected  by  requiring  verbalization.  The  effect  of 
verbalization  on  cognitive  processes  is  once  again  dependent  upon  the 
instructions  given  to  the  subjects.  There  are  three  levels  of  verbalization 
(Ericsson  &  Simon,  1984).  The  first  level  is  vocalization  of  a  thought  that 
is  already  verbally  encoded.  When  the  contents  of  short-term  memory  are 
words,  the  words  can  be  spoken  without  interfering  with  ongoing  cognitive 
processes.  This  level  takes  no  special  effort  and  places  no  additional 
demands  on  processing  time  or  capacity.  Performance  time  in  nearly  all 
studies  reviewed  was  the  same  for  both  verbalization  and  control  conditions. 
The  second  level  involves  description  of  thoughts.  Some  information  is 
stored  in  memory  in  non-verbal  form;  visually  encoded  thoughts,  for  example. 
Thought  in  this  form  can  proceed  much  faster  than  speech.  Complete 
verbalization  of  non-verbal  thoughts  takes  time  and  thus  slows  down  the 
thinking  itself.  No  new  information  is  introduced,  but  processing  time  is 
required  to  label  existing  information.  At  the  third  level,  thought 
processes  are  not  only  vocalized,  but  also  explained.  Subjects  are 
reporting  thoughts  about  information  that  was  previously  attended  to  and 
may  therefore  not  be  as  complete  or  accurate.  Subjects  may  also  incorrectly 
infer  the  experimenter's  motives  or  causes  (Ericsson  &  Simon,  1984). 

Therefore,  it  is  up  to  the  experimenter  to  ensure  that  instructions 
elicit  verbalizations  in  levels  one  and  two  only.  The  most  important 
distinction  is  whether  the  instructions  require  the  subjects  to  merely 
describe  their  thoughts  or  to  explain  them.  The  accuracy  of  protocol 
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analysis  dapands  upon  not  asking  for  anything  that  raquiras  intarpratation. 
Reprocessing  may  changa  tha  thought  procaasas  thamsalvas. 

Warm-up  problams  can  ba  usad  to  gat  subjacta  to  think  aloud  and  bacoma 
comfortabla  with  tha  microphona  (Ericsson  &  Simon,  1984).  During  varm-up 
problams,  tha  experimenter  can  interrupt  and  explain  whether  tha  subjects 
are  verbalizing  correctly  or  Incorrectly.  This  helps  the  subjects  to 
understand  what  is  required  of  them.  During  tha  actual  experiment,  any 
reminders  to  keep  talking  need  to  ba  kept  short  so  they  will  not  interfere 
with  the  subject's  processing. 

Experimenters  must  also  recognize  that  the  processes  underlying  some 
behavior,  like  recognition,  may  be  unconscious  and  therefore  not  reportable. 
The  results  of  these  processes,  hovaver,  can  still  help  to  clarify 
strategies  used,  inferences  made,  and  what  is  recognized  (Ericsson  &  Simon, 
1984). 

Ericsson  and  Simon  (1984)  have  outlined  four  steps  in  protocol  analysis. 
First,  a  tape  recording  is  made  of  people  who  are  thinking  aloud  while 
solving  problems.  The  tape  recording  is  then  transcribed  into  individual 
statements.  Next,  tha  statements  are  encoded  into  previously  determined 
theoretical  categories.  When  behavior  commonalities  need  to  be  determined, 
the  statements  can  be  coded  at  more  aggregated  levels  than  individual 
statements.  Finally,  the  encoded  data  are  analyzed  to  determine  the 
reasoning  strategies  usad.  Specific  comparisons  can  be  made  among  the 
protocols.  An  informal  analysis  can  also  be  performed  on  protocol  data, 
without  encoding  or  a  priori  hypotheses,  to  obtain  information  about 
problem-solving  methods  (Ryder  at  al.,  1988). 

II.  METHODOLOGY 

Subjects 

No  small  sample  of  programmers  can  be  considered  representative  of  the 
population  of  programmers,  since  no  standard  type  of  individual  becomes  a 
programmer.  Education,  job  title,  experience,  and  vork  skills  differ 
radically  (Guidon  at  al.,  1987).  In  prior  debugging  studies,  each 
researcher  established  his  own  set  of  criteria  for  determining  who  was  an 
experienced  programmer.  Often  college  seniors  or  graduate  students  in 
computer  science,  with  little  professional  experience,  were  classified  as 
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experts.  The  present  research  used  two  separate  standards  for  defining 
expert  programmers.  First,  these  subjects  had  to  be  programmers  with  at 
least  2  years  of  professional  programming  experience.  Second,  the  subjects 
had  to  complete  the  required  tasks  in  a  specified  amount  of  time,  which  was 
determined  through  pre-tests  to  be  insufficient  for  novices. 

Twelve  professional  C  programmers  volunteered  to  serve  in  this 
experiment.  C  was  chosen  because  of  its  wide  usage  and  the  availability  of 
subjects.  All  of  the  programmers  were  connected  with  the  Operations 
Training  Division  of  the  Air  Force  Human  Resources  Laboratory  and  employed 
by  Government  contractors.  All  had  at  least  2  years  of  professional 
programming  experience  and  C  was  the  preferred  programming  language  of  each. 

Equipment 

The  subjects  were  placed  in  a  closed  office  for  the  experiment.  They 
did  their  programming  on  a  video  terminal  attached  to  a  VAX  computer  with 
the  VMS  operating  system.  The  operating  system  was  augmented  to  save  a  copy 
of  the  source  code  every  time  a  subject  exited  the  EDT  editor.  The  subjects 
were  given  pencil  and  paper  for  scratch  work,  along  with  a  calculator  and  a 
copy  of  the  initial  program.  For  reference,  they  had  editor  usage 
instructions,  debugger  usage  instructions,  and  two  VAX  C  programming 
manuals.  A  printer  was  also  supplied. 

Protocol  data  were  collected  by  recording  the  subjects'  vocalized 
thoughts.  As  asserted  by  Ericsson  and  Simon  (1984),  experts  sometimes 
automate  portions  of  their  task  performance  to  the  point  that  they  lose 
conscious  knowledge  of  some  aspects  of  the  task;  thus,  the  explanations  may 
not  match  their  actual  processing  mechanisms.  Therefore,  in  addition  to 
recording  each  subject's  verbalizations,  the  video  output  from  the  terminal 
was  captured  on  videotape.  The  video  output  was  used  to  fill  in  gaps  when 
the  subject  did  not  vocalize  some  of  the  coding. 

Procedures 

For  a  protocol  analysis,  Ryder  et  al.  (1988)  noted  that  the  problems 
need  to  be  typical  or  representative  of  the  job  domain,  taking  time  and 
subject  availability  into  account.  Ryder  et  al.  also  pointed  out  that  for 
complex  tasks,  preliminary  evaluation  is  necessary  to  select  tasks  that  are 
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sufficiently  difficult.  The  tasks  should  represent  bottlenecks,  yet  not  be 
so  difficult  that  no  one  knows  where  to  begin.  On  that  basis,  four  complex, 
yet  do-able  programming  tasks  were  chosen  for  this  experiment. 

The  first  task  was  to  sum  an  array  of  numbers  and  output  the  results  to 
a  file.  This  task  was  intended  to  be  a  warm-up  task,  giving  the  programmers 
time  to  become  accustomed  to  the  programming  environment.  The  second  task 
was  to  find  the  square  root  of  the  sum  to  within  .01,  without  using  any 
built-in  square  root  functions.  This  task  tests  the  ability  to  converge  on 
a  given  value.  The  third  task  required  that  each  number  in  the  array  be 
converted  to  octal.  This  task  tested  the  ability  to  use  different 
representations.  The  final  task  was  to  read-in  a  number  from  the  terminal 
and  use  a  binary  search  to  locate  the  number  in  the  sorted  array.  Although 
the  concept  is  simple,  Knuth  (1971)  found  that  over  80%  of  experienced 
programmers  write  the  logic  for  a  binary  search  incorrectly  the  first  time. 
This  task  seemed  appropriate,  because  the  present  research  is  studying 
debugging  techniques. 

Shneiderman  (1986)  stated  that  it  is  necessary  for  researchers  to 
conduct  at  least  one  pilot  test  of  materials  and  procedures  for  experiment 
refinement.  Protocols  were  collected  from  part-time  programmers  before  the 
actual  experiment  began.  They  were  given  an  unlimited  amount  of  time  to 
complete  all  four  tasks  while  vocalizing  their  thoughts.  Two  of  the  four 
programmers  completed  the  tasks  in  under  6  hours.  The  other  two  gave  up 
after  4  hours.  Mental  and  physical  fatigue  seemed  to  affect  each  subject's 
performance  and  attitude  after  the  3  1/2-hour  point.  All  of  the  subjects 
spent  a  great  deal  of  time  trying  to  figure  out  where  to  begin  on  the  square 
root  problem,  and  several  had  forgotten  how  the  octal-based  numbering  system 
worked. 

Based  on  these  findings,  the  instructions  were  modified  somewhat  for 
the  actual  experiment.  The  final  experimental  procedure  was  as  follows. 

The  subjects  were  first  asked  to  fill  out  a  background  questionnaire  and 
answer  a  few  questions  about  their  personal  experience  with  debuggers  (see 
Appendix  A).  They  were  then  introduced  to  the  experiment  setup  and  asked 
three  warm-up  questions  (see  Appendix  B)  to  give  them  practice  in  thinking 
aloud.  When  the  subjects  were  comfortable  thinking  aloud,  they  were  given  a 
set  of  written  instructions  (see  Appendix  B)  and  asked  to  complete  three 
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programming  tasks.  The  tasks  were  to  sum  an  array  of  numbers,  convert  each 
number  to  octal,  and  perform  a  binary  search  for  an  input  number.  The 
subjects  were  instructed  to  think  aloud  and  the  experimenter  prompted  them 
if  they  remained  quiet  for  too  long.  The  subject's  voice  was  recorded  on 
the  audio  track  of  a  videotape.  The  video  output  from  the  subject's 
terminal  was  captured  on  the  video  track  of  the  same  tape. 

The  time  limit  was  3  1/2  hours.  A  one-line  time  stamp  appeared  on  the 
subject's  screen  every  10  minutes.  It  said,  "TIME  xtxx.xx  -  If  in  Editor, 
press  CTRL-W  to  refresh  screen."  Although  the  time  stamp  interrupt  may  have 
momentarily  affected  the  subject's  thought  process,  this  study  did  not 
address  that  issue.  Interrupts  of  this  type  are  not  uncommon  in  programming 
environments.  Timing  and  taping  began  when  the  subject  started  reading  the 
instructions  and  ended  when  he  was  finished  and  the  experimenter  had  tested 
the  complete  program. 


III.  RESULTS 
Questionnaire  Results 

Background  Variables 

Of  the  12  subjects  who  took  part  in  this  study,  only  eight  completed  all 
three  programming  tasks.  By  the  criteria  listed  in  Section  II,  these  eight 
were  classified  as  experts  and  their  data  were  further  analyzed.  The  eight 
who  finished  and  the  four  who  did  not  were  also  compared  on  variables 


Table  1.  Background  Comparison  of  Programmers  Who  Finished  the  Tasks 
vs.  Programmers  Who  Did  Not  Finish  the  Tasks 


Finished  (n 

=  8) 

Did  Not  Finish  (n 

=  4) 

Background  Variable 

Mean 

Min 

Max 

Mean 

Min 

Max 

Yrs  work  with  computers 

8.6 

2 

18 

7.8 

3 

12 

Yrs  professional  programming 

4.4 

2 

10 

3.3 

2 

Hrs/wk  spent  programming 

22.5 

15 

30 

20.0 

0 

Number  programming  languages 

5.5 

4 

9 

6.0 

4 

Number  operating  systems 

5.0 

3 

4.3 

2 

8 

Yrs  post-secondary  education 

4.0 

2 

6 

4.3 

4 

C 

13 


measuring  background  experience  (see  Table  1).  The  programmers  who  were  not 
able  to  complete  the  tasks  had  averaged  slightly  fewer  years  working  with 
computers  and  programming. 

Debugger  Use 

Various  debuggers  were  available  for  use  by  all  of  the  subjects  in  their 
current  jobs.  However,  three  of  the  programmers  stated  that  they  had  never 
used  a  debugger  to  help  them  debug  their  code.  Reasons  given  were  that  they 
did  not  think  the  debugger  would  be  very  useful  since  they  usually  debugged 
their  code  fairly  quickly  without  it,  and  that  they  did  not  have  time  to 
learn  how  to  use  a  debugger.  One  subject  simply  stated  that  he  made  few 
mistakes. 

The  other  nine  programmers  had  used  at  least  one  debugger.  Their  usage 
experience  included  the  VAX  debugger  on  VMS,  Microsoft  CodeView  on  MS-DOS, 
sdb  on  UNIX  and  DBx  Tool  on  Sun  Workstations.  Most  of  the  programmers  said 
that  they  learned  the  debugger  well  enough  to  use  it  productively  within  one 
week.  Still,  these  programmers  tended  to  use  the  debuggers  only  as  a  last 
resort.  They  stated  that  they  use  debuggers  when  other  methods  do  not  work; 
e.g.,  after  debug  print  statements  and  hand-simulation. 

The  most  frequently  used  debugger  features  were  displaying  variable  and 
register  values,  setting  breakpoints,  and  single-stepping  through  code. 
Programmers  complained  about  the  lack  of  meaningful  mnemonics  when  assigning 
control  keys  to  commands  (e.g.,  F7  =  STEP,  rather  than  CTRL-S). 

Prograaming/Debugging  Results 

All  the  subjects  attempted  the  tasks  in  the  given  numbered  order, 
completing  each  task  before  proceeding  to  the  next  task.  Although  the  VAX 
interactive  debugger  was  available,  none  of  the  subjects  used  it.  The  four 
subjects  who  were  stopped  at  the  3  1/2-hour  point  were  nowhere  near 
completion.  None  of  them  had  finished  task  two;  so  they  had  not  even 
attempted  task  three.  The  other  eight  subjects  completed  all  three  tasks. 

As  each  task  was  finished,  the  completion  time  and  the  number  of  times  the 
editor  was  used  were  noted  (see  Table  2).  A  task  was  considered  complete 
when  the  working  version  was  saved  in  the  editor.  The  amount  of  time  spent 
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on  each  task  varied  for  tasks  one  and  two,  but  the  time  spent  on  task  three 
was  near  1  hour  for  all  eight  subjects. 

Table  2.  Programming/Debugging  Times  and  Number  of  Editor  Uses 


s 

If 

Time  to  Complete  Each  Task 

Number  of  Times  Editor  Used 

B 

Tsk  1 

Task  2 

Task  3 

Total 

Task  1 

Task  2 

Task  3 

_ 

Total 

10 

1  hr 

1 

4 

EM 

14 

#1 

min 

28  min 

56  min 

34  min 

edit 

edits 

EM 

edits 

27 

m 

MSI 

10 

6 

n 

MB 

#2 

min 

32  min 

edits 

edits 

edits 

EM 

6 

1  hr 

1 

Mi 

MB 

14 

#3 

min 

36  min 

57  min 

39  min 

edit 

edits 

10 

bee 

1  hr 

3 

9 

EH 

20 

#4 

min 

38  min 

50  min 

edits 

edits 

edits 

9 

1  hr 

1  hr 

5 

7 

8 

27 

#5 

min 

27  min 

1  min 

37  min 

edits 

edits 

edits 

edits 

59 

ns 

1  hr 

mm 

18 

8 

15 

41 

#6 

min 

4  min 

SEE 

edits 

edits 

edits 

edits 

13 

1  hr 

1  hr 

2  hr 

mm 

6 

23 

#7 

min 

26  min 

14  min 

53  min 

EB 

edits 

edits 

edits 

21 

1  hr 

1  hr 

3  hr 

EM 

12 

10 

25 

#8 

min 

40  min 

34  min 

30  min 

EM 

edits 

edits 

edits 

A 

MU 

MB 

ME 

EM 

V 

20 

R 

2  hr 

10 

G 

min 

50  min 

16  min 

Em 

EM 

edits 

EM 

Before  the  protocol  data  could  be  analyzed,  the  possible  cognitive 
activities  that  could  occur  during  the  session  had  to  be  enumerated.  The 
problem  space  and  universe  of  operators  can  be  defined  either  through  pilot 
work  or  after  transcription  of  the  verbal  protocol  prior  to  encoding  (Ryder 
et  al.,  1988).  The  coding  categories  were  generated  based  on  the  pilot 
study  trials,  previous  studies,  and  programming  knowledge  (see  Table  3). 
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The  categories  were  then  formalized  using  functional  notation,  as  proposed 
by  Ericsson  and  Simon  (1984). 


Table  3.  Coding  Categories 


Code 

Meaning 

CALCULATE 

Code  calculation  of  named  variable(s) 

CHANGE 

Change  lines  of  source  code  as  indicated 

COMMENT 

Verbal  comment  made  by  subject 

COMPILE 

Compile  and  link  named  source  code 

DECLARE 

Code  declaration  of  named  variable(s) 

DELETE 

Delete  indicated  lines  of  source  code 

EDIT 

Edit  named  file 

ERROR 

Named  error  was  produced  by  compiler 

EXIT 

Exit  from  editor  and  save  named  file 

GOTO 

Move  to  indicated  place  in  source  code 

HANDCHECK 

Hand-simulate  code  or  hand-calculate  values 

INITIALIZE 

Code  sets  initial  value  for  named  variable 

INSERT 

Insert  lines  of  source  code 

NEED 

Necessary  action  verbalized  by  subject 

PRINT 

Code  prints  to  file  or  terminal  screen 

READ 

Reading  instructions,  manual  or  terminal  screen 

RUN 

Run  named  executable  code 

TEST 

Run  executable  code  with  indicated  input 

TYPEFILE 

Type  named  file  to  terminal  screen 

The  protocol  data  were  first  transcribed  into  English  phrases  and 
sentences.  The  phrases  and  sentences  were  then  coded  with  functional 
notations  using  the  categories  in  Table  3.  Any  statement  that  could  not  be 
encoded  was  placed  in  a  catchall  category,  COMMENT,  as  suggested  by  Ryder  et 
al.  (1988).  Video  and  source  code  data  were  incorporated  into  the  coded 
data  for  clarity  in  the  analysis  (see  Appendix  C).  The  types  of  errors  made 
and  the  techniques  used  to  find  the  errors  were  then  analyzed. 

The  subjects'  coded  data  were  examined  to  find  the  errors  that  had  to  be 
debugged.  This  search  began  following  the  first  exit  from  the  editor  for 
each  task.  Any  changes  made  before  the  first  exit  were  not  counted,  because 
a  debugger  cannot  be  used  until  the  first  version  of  the  source  code  is 
typed  in.  Errors  were  isolated  by  working  backwards  from  the  changes  made 
to  the  code.  Each  error  was  identified  and  grouped  into  one  of  the  classes 
described  in  Section  I  (see  Table  4).  The  syntax  errors  were  subdivided 
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into  those  caught  by  the  compiler  and  those  caught  by  the  programmer.  The 
technique  the  subject  used  to  find  the  error  was  also  noted. 

Table  4.  Error  Classification 


Subject 

Type  of  Error 

#1 

#2 

#3 

#4 

#5 

#6 

#7 

#8 

Totals 

Appreciation 

1 

0 

n 

1 

0 

1 

1 

B 

5 

Lexical/Syn tactic 

Found  by  Compiler 

6 

5 

H 

3 

3 

16 

5 

H 

49 

Found  by  Programmer 

3 

0 

B 

0 

0 

6 

1 

B 

12 

Execution 

n 

2 

0 

1 

0 

2 

3 

0 

8 

Intent/Logic 

n 

2 

10 

10 

16 

8 

6 

12 

68 

Total  Errors  Made 

14 

9 

15 

15 

19 

33 

16 

21 

142 

The  five  appreciation  errors  were  of  two  types.  Subjects  1,  6  and  7  did 
not  initially  format  their  sum  output  correctly.  Subjects  4  and  8  tried  to 
use  the  "%o"  print  format  to  output  the  octal  representations  instead  of 
actually  converting  the  numbers.  As  expected,  most  of  the  lexical/syntactic 
errors  were  caught  by  the  compiler.  Even  the  lexical/syntactic  errors  that 
the  programmers  had  to  find  themselves,  however,  were  discovered  fairly 
quickly  by  simply  reading  through  the  code.  The  most  common  synt'x  errors 
were  incorrect  spellings,  missing  punctuation,  incorrect  use  of  operators, 
and  missing  declarations.  The  execution  and  logic  errors  were  the  hardest 
to  locate  and  fix.  All  of  the  execution  errors  occurred  due  to  access 
violations,  when  the  programmer  tried  to  access  an  address  in  memory  that 
was  beyond  the  legal  bounds  of  the  program.  The  most  common  logic  errors 
were: 

1.  variables  not  initialized 

2.  incorrect  array  indices 

3.  variable  values  calculated  incorrectly 

4.  loop  exit  condition  incorrect 

5.  digits  of  the  octal  representation  reversed 
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6.  no  code  for  case  when  number  was  not  in  the  array 

7.  boundary  conditions  not  checked  by  algorithm 

Most  of  the  subjects  used  the  same  debugging  strategy.  After  the  first 
version  of  each  task  was  coded  in  the  editor,  the  compiler  was  used  to  find 
the  syntax  errors.  Once  the  syntax  errors  had  been  fixed,  the  programmers 
ran  the  program  and  examined  the  output.  If  the  output  did  not  look 
correct,  the  code  was  reviewed.  If  the  error  was  not  obvious,  debugging 
print  statements  were  inserted  in  the  code  and/or  a  hand-simulation  of  the 
code  was  carried  out  on  paper.  The  programmers  then  ran  the  program  and 
examined  the  output  again.  Eventually,  some  combination  of  debug  print 
statements  and  hand-simulation  would  reveal  the  error's  cause.  After  the 
error  was  fixed,  the  program  was  run  again  to  see  the  effects  of  the 
changes.  Overall,  the  programmers  used  the  code,  the  output,  debug  print 
statements,  and  hand-simulation  to  find  their  bugs.  It  is  interesting  to 
note  that  many  of  the  bugs  were  corrected  before  the  first  code  was  even 
entered.  The  programmers  often  hand-simulated  their  code  to  a  cer*--  in 
extent  before  coding,  revealed  their  initial  errors,  and  fixed  them  Before 
they  actually  typed  in  the  code. 


IV.  DISCUSSION 

This  experiment  differs  from  previous  debugging  studies  in  that  it 
examines  programmers  as  they  debug  their  own  code  instead  of  finding 
specific  bugs  placed  in  an  experimental  program.  Thus  it  allows  for  a 
greater  variety  of  error  types,  and  therefore  a  more  complete  study  of 
debugging  techniques. 

The  results  of  this  experiment  provide  some  insight  into  programmers' 
use  of  and  attitude  toward  interactive  debuggers.  The  programmers' 
debugging  techniques,  insertion  of  debug  print  statements  and  hand- 
simulation  are  supported  by  most  debuggers.  Instead  of  inserting  debug 
print  statements,  a  programmer  can  use  a  debugger  to  show  variable  values  at 
any  point  during  execution.  Similarly,  the  programmer  can  use  the  debugger 
to  step  through  the  code,  instead  of  performing  a  hand-s'mulation  on  paper. 
The  results  would  be  more  accurate,  in  that  the  system  would  not  overlook 
any  line  of  code. 


18 


Even  though  using  the  debugger  would  have  been  simpler,  none  of  the 
subjects  in  this  experiment  did  so.  Half  of  the  subjects  were  not  familiar 
with  the  VMS  environment,  which  would  explain  their  reluctance  to  try  a  new 
debugger.  The  other  half  did  not  feel  that  the  program  was  complicated 
enough  to  warrant  its  use.  The  debugger  was  seen  only  as  a  last  resort,  if 
they  could  not  debug  the  program  by  hand. 

The  results  of  this  experiment  imply  that  debuggers  would  be  used  more 
frequently  if  they  were  easier  to  learn.  Therefore,  the  designers  should 
now  concentrate  on  the  presentation  of  the  debugger,  as  the  programmers' 
functional  needs  are  being  met.  This  area  includes  interface  design, 
documentation,  and  marketing.  When  a  piece  of  software  is  designed  for  a 
naive  user,  a  great  deal  of  time  and  effort  are  spent  on  making  the  product 
easy  to  use.  When  the  market  for  a  software  product  is  computer 
professionals  (proficient  computer  users),  however,  manufacturers  place  less 
emphasis  on  ease  of  use.  On  the  questionnaires  though,  several  subjects 
expressed  interest  in  simple  tutorials  for  debuggers,  as  well  as  more 
examples  to  follow. 

Product  support  for  software  debuggers  typically  consists  of  a  single 
reference  manual.  The  manual  is  usually  very  thick  and  covers  every  command 
the  debugger  supports.  The  results  of  the  present  experiment  show  there  are 
only  about  five  debugger  commands  that  would  be  used  by  all  programmers. 
These  commands  allow  the  programmer  to  single-step  through  a  program,  set 
breakpoints,  display  variables  and  registers,  and  set  new  values.  These 
commands  should  be  made  so  easy  to  use  that  they  take  only  minutes  to  learn. 
The  debugger  documentation  should  introduce  these  commands  first,  instead  of 
burying  them  in  with  the  rest  of  the  commands.  The  programmers  could  then 
use  the  debugger  productively  with  very  little  effort.  The  more  complex, 
less-used  commands  could  then  be  learned  as  they  become  necessary. 

The  results  of  this  experiment  also  indicate  that  programmers  would  be 
interested  in  specifying  certain  variables  for  the  debugger  to  display 
constantly.  The  interface  could  be  designed  such  that  a  portion  of  the 
screen  would  be  reserved  for  displaying  variable  values.  The  programmer 
would  not  have  to  ask  to  see  the  value  of  each  variable  every  time  the 
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execution  paused.  Before  executing  the  code  in  the  debugger,  the  programmer 
would  name  the  variables  to  be  displayed  at  every  stopping  point. 

There  are  several  ways  these  features  could  be  implemented  that  would 
make  them  easy  to  use.  Debuggers  designed  around  a  command  language  could 
ensure  that  the  five  most-used  commands  were  accessible  using  one-letter  or 
one-key  commands.  Debuggers  designed  around  menu  interfaces  could  include 
pulldown  menus  for  the  most-used  features.  No  matter  what  method  of 
implementation  is  employed,  ease  of  use  should  be  the  primary  concern. 

V.  CONCLUSIONS  AND  RECOMMENDATIONS 

This  research  provided  some  understanding  of  the  debugging  techniques 
used  by  professional  programmers.  One  of  the  limitations  of  studying 
programmers  debugging  their  own  code,  however,  was  that  the  task  complexity 
had  to  be  limited.  The  tasks  had  to  be  modified  so  that  the  programmers 
could  complete  them  in  one  sitting.  It  would  be  interesting  to  see  if 
hand-simulation  and  debug  print  statements  were  used  as  frequently  in  coding 
more  complex  problems.  This  research  did  not  address  integration  or 
portability  issues  either.  The  methods  used  to  debug  code  during  an 
integration  effort  may  be  entirely  different. 

The  data  for  this  experiment  were  collected  using  only  C  programmers,  a 
subset  of  the  programming  world.  Further  research  should  be  conducted  to 
see  if  the  results  apply  to  programmers  as  a  whole.  The  results  of  this 
experiment  show  that  debuggers  are  difficult  to  learn  but  are  functionally 
well  designed.  Future  research  should  focus  on  the  best  ways  to  improve  the 
documentation  and  user  interface,  so  that  they  will  be  used  more  frequently. 
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APPENDIX  A:  SAMPLE  QUESTIONNAIRE 


SAMPLE  QUESTIONNAIRE 


1.  Are  you  male  or  female? 

2.  How  old  are  you? 

3.  What  education  level  have  you  achieved? 

(High  School,  Some  College,  Associate  Degree,  Bachelors  Degree, 
Some  Graduate  Courses,  Masters  Degree,  Doctoral  Degree...) 

4.  If  you  completed  a  degree  or  degrees,  what  was  your  major  field 
of  study?  (undergraduate,  and  graduate  if  applicable) 

5.  Did  you  learn  to  program  on  a  batch  or  an  interactive  system? 

6.  How  many  months/years  have  you  been  in  the  computer  field? 

7.  How  many  months/years  have  you  been  programming  professionally? 

8.  How  many  hours  per  week  do  you  currently  spend  programming? 

9.  How  many  different  operating  systems  have  you  used? 

10.  Are  you  familiar  with  the  VAX/VMS  operating  system? 

11.  How  many  programming  languages  have  you  programmed  in? 

12.  What  is  your  preferred  programming  language? 

13.  Do  you  ever  use  a  debugger  to  help  debug  code? 

14.  If  the  answer  to  #13  was  "NO": 


a.  Is  a  debugger  currently  available  for  your  use? 

b.  If  "YES,"  why  don't  you  use  it? 


15.  If  the  answer  to  #13  was  "YES": 

a.  Which  debugger(s)  have  you  used? 

b.  How  many  weeks/months  did  it  take  you  to  learn  this  debugger 
well  enough  to  use  it  productively? 

c.  Under  what  circumstances  do  you  use  the  debugger? 

d.  What  debugger  features  do  you  use  most  frequently? 

e.  What  features  in  this  debugger  (or  these  debuggers)  are  the 
most  cumbersome? 


f.  How  would  you  suggest  that  they  be  improved? 

g.  What  additional  features  would  you  like  to  see  incorporated  in 
debuggers? 

16.  What  methods,  other  than  interactive  debuggers,  do  you  use  to 
debug  code? 
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APPENDIX  B:  STUDY  INSTRUCTIONS 
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VERBAL  SCRIPT 


Please  fill  out  the  questionnaire. 

Warm-Up  Problems; 

In  this  experiment  we  are  interested  in  what  you  think  about  when  you 
program,  test,  and  debug.  We  are  especially  interested  in  what  you  are 
thinking  whenever  you  notice  anything  wrong  -  either  in  your  logic  or  your 
coding,  and  how  you  find  and  correct  the  error.  Therefore,  I  want  you  to 
THINK  ALOUD  as  you  work  on  each  task. 

What  I  mean  by  think  aloud  is  that  I  want  you  to  tell  me  everything  that 
passes  through  your  head  from  the  time  you  first  read  the  instructions  for 
the  task  until  you  have  a  working  version  of  the  program.  TALK  CONSTANTLY. 

I  don't  want  you  to  plan  out  what  you  say  or  try  to  explain  to  me  what  you 
are  saying.  Just  act  as  if  you  are  alone  in  the  room  speaking  to  yourself. 

IT  IS  VERY  IMPORTANT  THAT  YOU  KEEP  TALKING.  If  you  are  silent  for  a 
long  period  of  time,  I  will  remind  you  to  keep  talking.  ALSO  SPEAK  LOUDLY. 
Do  you  understand  what  I  want  you  to  do? 

To  get  you  used  to  the  idea  of  thinking  aloud,  I'm  going  to  ask  you  a 
few  warm-up  questions.  I  want  you  to  think  aloud  as  you  figure  out  the 
answers. 

1.  How  nuch  is  384  divided  by  16?  (24) 

Good.  Now  I  want  to  see  how  much  you  can  REMEMBER  about  what  you  were 
thinking  from  the  time  you  heard  the  question  until  you  gave  the  answer.  If 
possible  I  would  like  you  to  tell  me  about  your  memories  in  the  sequence 
they  occurred  while  working  on  the  question.  I  don't  want  you  to  work  on 
solving  the  problem  again;  just  report  all  that  you  can  remember  thinking 
about  when  answering  the  question. 

Good.  I  will  give  you  two  more  practice  problems.  I  want  you  to  do  the 
same  thing  for  each  of  these  problems.  Here's  your  next  problem. 

2.  Hov  many  windows  are  there  in  your  house? 

Now  tell  me  all  that  you  can  remember  about  your  thinking. 

Here  is  your  last  practice  problem.  Think  aloud  as  you  answer.  There 
is  no  need  to  keep  count.  I  will  keep  track  for  you. 

3.  Name  20  animals. 

Now  tell  me  all  that  you  can  remember  about  your  thinking. 
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VERBAL  SCRIPT 


Main  Experiment : 

You  will  be  given  three  programming  tasks  to  do.  Complete  the  tasks  in  any 
order.  If  you  have  a  trouble  solving  any  problem,  proceed  to  the  next  task, 
and  come  back  to  it  later. 

Do  you  have: 

1.  Hardcopy  of  the  source  code? 

2.  File  containing  source  code? 

3.  Copy  of  the  desired  output? 

4.  Experiment  Instructions? 

5.  Paper  and  Pencil? 

6.  Calculator? 

7.  Terminal  and  Printer  Access? 

8.  "Use  of  Compiler  &  Editor"  Instructions? 

9.  Editor  Keys  Handout? 

10.  Debugger  Instructions? 

11.  Language  Manuals? 


Varning: 

Your  screen  will  be  time-stamped  every  10  minutes. 

If  you  are  in  the  editor,  use  Control-W  to  refresh  your  screen. 
Ignore  the  time  stamp  and  continue  to  work. 

Final  Reminders: 

If  you  are  typing  in  or  reading  your  code,  you  can  read  aloud. 

TALK  CONSTANTLY 
SPEAK  LOUDLY 
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WRITTEN  INSTRUCTIONS 


Programming  Tasks: 

Expand  the  functionality  of  the  program  in  file  PROG.C  so  that  it  will  do 
the  following  (NOTE:  Do  NOT  create  a  new  file.  Edit  the  existing  PROG.C 
f ile) : 


1.  Compute  the  sum  of  all  of  the  numbers  in  the  array.  Output  the  sum  to  a 
results  file.  See  the  attached  example  of  desired  output. 

(REMEMBER  TO  THINK  ALOUD) 


2.  Convert  each  number  in  the  array  to  octal.  See  the  conversion  examples 
below.  (Note:  You  must  actually  convert  each  number,  not  just  output 
the  number  with  the  %o.)  Output  the  decimal  and  octal  conversion 
representations  of  each  entry  to  the  results  file.  See  the  attached 
example  of  desired  output.  (REMEMBER  TO  THINK  ALOUD) 


In  decimal,  digits  signify  the  quantity  of  each  power  of  10. 
i.e.  9371q  =  (9  x  102)  +  (3  x  101)  +  (7  x  10°) 

In  octal,  the  digits  work  the  same  way. 

i.e.  9371q  =  1651g  =  (1  x  83)  +  (6  x  82)  +  (5  x  81)  +  (1  x  8°) 


Conversion  By  Division: 

937  /  8  -  117  rem  1 

117  /  8  -  14  rem  5 

14  /  8  =  1  rem  6 

1  /  8  =»  0  rem  1 


Conversion  By  Subtraction: 
937  -  (1  x  83)  =  425 

425  -  (6  x  82)  =  41 

41  -  (5  x  81)  =  1 

1  -  (1  X  8°)  =  0 


3.  Prompt  for  a  number  between  1  and  50  from  the  terminal.  Use  a  binary 
search  to  locate  the  number  in  the  given  sorted  array. 


Binary  search: 


-Compare  input  number  to  middle  entry  of  array. 

-If  input  number  is  smaller,  repeat  search  on  first  half  of  array. 

-If  input  number  is  larger,  repeat  search  on  second  half  of  array. 
-Repeat  search  until  input  number  is  found  or  determined  not  to  exist 
in  array. 


If  the  input  number  is  found,  output 
where  it  is  located  to  the  terminal, 
output  a  message  stating  that  fact. 


the  number  and  the  array  index 
If  the  input  number  is  not  found, 
(REMEMBER  TO  THINK  ALOUD) 
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WRITTEN  INSTRUCTIONS 


Initial  Program 

linclude  <stdio.h> 
main( ) 

/*  This  program  initializes  array  of  integers.  */ 

{ 

int  nums[20]  =  {1,3,5,8,9,12,13,19,25,26,27,29,33,35,38,39,40,43,45,50}; 
printf  ("The  NUMS  array  has  been  initialized. \n"); 

} 


Desired  Output: 

In  the  RESULTS  file  (for  tasks  1  and  2): 


Array 

Array 

Sum  =  n 

Decimal 

Octal 

Index 

Rep 

Rep 

n 

n 

n 

• 

• 

• 

• 

• 

• 

• 

. 

• 

n 

n 

n 

To  the  TERMINAL  (for  task  3): 

Input  number,  n,  found  at  array  index  n. 
or 

Input  number,  n,  does  not  exist  in  the  array. 
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WRITTEN  INSTRUCTIONS 


Compiler  and 
EDITOR: 


COMPILER: 


Miscellaneous 


DIRECTORY 

LISTING: 

FILE 

CONTENTS: 

HOLD 

SCREEN: 


Edi tor: 


To  edit  the  file: 

$  EDIT  PROG.C 

To  exit  the  editor  and  save  your  file: 

Hit  the  <F10>  key. 

To  compile,  link  and  run  the  file: 

$  CC  PROG  (with  listing  file:  $  CC/LIST  PROG) 

$  LINK  PROG,  SYS$LIBRARY:VAXCRTL/ LIBRARY 
$  RUN  PROG 

To  compile,  list,  and  link  at  the  same  time: 

$  CLL  PROG 


To  compile,  link  and  run  the  file  with  the  debugger: 
$  CC/DEBUG  PROG 

(with  listing  file:  $  CC/DEBUG/LIST  PROG) 
$  LINK/ DEBUG  PROG 
$  RUN  PROG 

To  compile,  list,  and  link  with  the  debugger: 

$  CLD  PROG 


VAX  Commands: 


To  display  names  of  files  in  your  directory: 
$  DIR 


To  display  the  contents  of  a  file  in  your  directory: 
$  TYPE  filename 


To  pause  the  scrolling  of  output  on  your  screen,  press: 
<F1>  key  (Press  again  to  resume  output  display.) 
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APPENDIX  C:  SAMPLE  SUBJECT  DATA 


DATA  SOURCES: 

P  -  Protocol  (Verbal)  Data 
S  =  Source  Code  (from  Edit  Sessions)  Data 
V  =  Videotape  Data 


CODING  CATEGORIES: 


CALCULATE 

CHANGE 

COMMENT 

COMPILE 

DECLARE 

DELETE 

EDIT 

ERROR 

EXIT 

GOTO 

HANDCHECK 

INITIALIZE 

INSERT 

NEED 

PRINT 

READ 

RUN 

TEST 

TYPEFILE 


-  Code  calculation  of  named  variable(s) 

-  Change  lines  of  source  code  as  indicated 

-  Verbal  comment  made  by  subject 

-  Compile  and  link  named  source  code 

-  Code  declaration  of  named  variable(s) 

-  Delete  indicated  lines  of  source  code 

-  Edit  named  file 

-  Named  error  was  produced  by  compiler 

-  Exit  from  editor  and  save  named  file 

-  Move  to  indicated  place  in  source  code 

-  Hand-simulate  code  or  hand-calculate  values 

-  Code  sets  initial  value  for  named  variable 

-  Insert  lines  of  source  code 

-  Necessary  action  verbalized  by  subject 

-  Code  prints  to  file  or  terminal  screen 

-  Reading  instructions,  manual  or  terminal  screen 

-  Run  named  executable  code 

-  Run  executable  code  with  indicated  input 

-  Type  named  file  to  terminal  screen 
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SUBJECT  #2  DATA 


TIME 

P 

PV 

PV 

s 

p 

PV 

s 

PV 

s 

p 

PV 

PV 

s 

PV 

s 

p 

PV 

s 

PV 

PV 

PV 

p 

PV 

PV 

s 

PV 

PV 

PV 

p 

PV 

P 

PV 

s 

PV 

PV 

P 

p 

PV 

p 

PV 

s 

p 

PV 

s 

TIME 

PV 

p 

PV 

s 

P 

p 

PV 

s 

PV 


0:00:00  -  TASK  #1 

READ  (INSTRUCTIONS  FOR  TASK  1) 

EDIT  (PROG.C) 

INSERT  (COMMENT) 

/*  sum  the  array  elements  */ 

COMMENT  (THERE'S  20  OF  THEM ,  SO  WE'LL  MAKE  A  LOOP  OF  20) 

INSERT  (FOR  LOOP) 

for  (i  =  0;  i=20;  i++) 

DECLARE  (INTEGER,  I) 
i  n  t  i  ; 

NEED  (PLACE  TO  COLLECT  THE  SUM) 

DECLARE  (INTEGER,  SUM) 

INITIALIZE  (SUM) 

i n t  i ,  sum=0 ; 

CALCULATE  (SUM,  FOR  EACH  ELEMENT) 
sum  +=  num [ i ] ; 

COMMENT  (ONLY  ONE  LINE  IN  THERE,  SO  WE  DON'T  NEED  BRACKETS) 

PRINT  (MESSAGE  TO  MAKE  SURE  WE  GOT  THROUGH  THERE)  TO  SCREEN 
prlntf  ("The  sum  of  the  NUM S  array  as  been  computed"); 

EXIT  (PROG.C) 

COMPILE  (PROG.C) 

ERROR  (NUM  IS  NOT  DECLARED  WITHIN  THE  SCOPE  OF  THIS  USAGE) 
COMMENT  (IT'S  NUMS ,  NOT  NUM) 

EDIT  (PROG.C) 

CHANGE  (NUM  TO  NUMS  IN  SUM  CALCULATION) 
sum  +=  nums [ i J ; 

EXIT  (PROG.C) 

COMPILE  (PROG.C) 

RUN  (PROG) 

READ  (SCREEN  -  NUMS  ARRAY  HAS  BEEN  INITIALIZED...  NOTHING  ELSE?) 
EDIT  (PROG.C) 

COMMENT  (OH,  MY  <  DIDN'T  MAKE  IT) 

CHANGE  (INSERT  <  IN  THE  FOR  LOOP  EXIT  CONDITION) 
for  ( i  =  0 ;  i <  =  2  0 ;  i++) 

EXIT  (PROG.C) 

COMPILE  (PROG.C) 

READ  (SCREEN  -  ...HAS  BEEN  INITIALIZED  AND  COMPUTED.  GOOD) 
COMMENT  (GET  BACK  IN  THE  EDITOR  AND  WRITE  IT  TO  A  FILE) 

EDIT  (PROG.C) 

NEED  (TO  WRITE  THE  RESULT  TO  A  FILE) 

INSERT  (COMMENT) 

/*  write  the  result  to  a  file  */ 

COMMENT  (LET'S  PRINT  THE  RESULTS  TO  THE  SCREEN  ALSO) 

PRINT  (SUM)  TO  SCREEN 

printf(”The  sum  of  the  NUMS  array  is  %d\n",  sum); 

0:10:00  -  TASK  #1 

INSERT  (OPEN  FILE,  RESULT . DAT ,  RETURNING  A  FILE  POINTER) 

READ  (INSTRUCTIONS  FOR  TASK  1  ON  NAME  OF  OUTPUT  FILE) 

CHANGE  (OPEN  IN  WRITE  MODE) 

fp  =  f open ( " result . da t " ,  "w+" ) ; 

READ  (MANUAL  -  LOOKING  FOR  FOPEN  ERROR  CHECKING) 

COMMENT  (CAN'T  FIND  IT,  SO  I'LL  ASSUME  THE  OPEN  WORKED) 

PRINT  (SUM)  TO  FILE 

fprintf(fp,  "The  sum  of  the  NUMS  array  is  %d\n",  sum) ; 

INSERT  (CLOSE  FILE) 
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s  fcloss(fp); 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  ERROR  (TP  NOT  DECLARED  WITHIN  THE  SCOPE  OF  THIS  USAGE) 

PV  EDIT  PROG.C 

PV  DECLARE  (FILE  POINTER,  FP) 

S  FILE  >fp; 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG.C) 

P  READ  (SCREEN  -  SUM  IS  1012) 

P  HANDCHECK  (ADD  ON  CALCULATOR  -  500?) 

P  COMMENT  (LET'S  SEE  WHAT  MV  DATA  FILE  LOOKS  LIKE) 

PV  TVPEFILE  ( RESULT . DAT ) 

P  COMMENT  (SAME  THING  -  MAYBE  SUM  WASN'T  GETTING  INITIALIZED) 

P  COMMENT  (LET'S  SEE  WHAT  SUM  WAS  BEFORE  I  STARTED  ADDING) 


PV 

PV 

PV 

s 

PV 

EDIT  (PROG.C) 

GOTO  (BEFORE  COMPUTATION  OF  SUM) 
PRINT  (SUM)  TO  SCREEN 

print ( "B«for»  computation,  sum 
EXIT  (PROG.C) 

was  %d\n" 

,  s  u  m  )  ; 

PV 

PV 

p 

COMPILE  (PROG.C) 

ERROR  (UNDEFINED  SYMBOL,  PRINT) 
COMMENT  (I  BET  I  TYPED  THAT  WRONG 

-  PRINTf 

WOULD  HELP) 

PV 

PV 

s 

PV 

EDIT  i PPOG  C • 

CHANGE  'PRINT  TO  PRINTF) 

printf  'Baf^r#  '-omputation,  sum 
EXIT  PROG 

was  %d\n 

"  ,  s  u  m  )  ; 

PV 

COMP  I LE  TPOG  ' 

TIME 

0:20:00  -  TASK  • 1 

PV 

RUN  (PROG1 

P  COMMENT  (STILL  GETTING  1012.  COULD  I  HAVE  ADDED  WRONG?) 

F  HANDCHECK  (ADD  ON  CALCULATOR...  500) 

PV  EDIT  (  PROG  .  C  I 

P  COMMENT  (I  GUESS  I  CAN  LOOK  AT  SUM  EACH  TIME) 

PV  PRINT  (SUM,  I,  AND  NUMS l I  1  I  TO  SCREEN  EACH  TIME 

S  pr  int  f  (  "  i*%d  ,  sum=*d,  nuns  (  i  )  =*%d\n  "  ,  i  ,  sun,  nuns  [  i  )  )  ; 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (  PROG  ) 

P  COMMENT  (I’M  STOPPING  AT  20  -  SHOULD  STOP  AT  19) 

P  COMMENT  (BUT  THE  SUM  WORKED.  WHY  DID  THE  PRINT  STATEMENT  FIX  IT?) 

* • EXPERIMENTOR  NOTE:  THE  VALUE  IN  NUMS[20)  FOR  THIS  SUBJECT  IS  UNRELIABLE  SINCE  IT  IS 

NOT  PART  OF  THE  DECLARED  ARRAY.  ON  THIS  RUN,  IT  HAPPENED  TO  BE 
EQUAL  TO  ZERO,  AND  THEREFORE  DID  NOT  HURT  THE  FINAL  SUM. 

PV  EDIT  (PROG.C) 

PV  CHANGE  (FOR  LOOP  EXIT  CONDITION  FROM  <20  TO  <19) 

S  for  (i  =  0;  i <  2  0 ;  i++) 

P  COMMENT  (BUT  PRINTING  SOMETHING,  SHOULDN’T  CHANGE  THE  ANSWER...) 

PV  CHANGE  (COMMENT  OUT  THE  PRINT) 

S  /‘print f (" i=%d ,  sun=%d,  nuns ( i !=%d\n" , i ,  sum,  nums(i));*/ 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

P  COMMENT  (500.  LOOKS  GOOD.  GO  CLEAN  OUT  THE  JUNK) 

PV  EDIT  (PROG.C) 

PV  DELETE  (TWO  DEBUG  PRINT  STMTS) 

P  COMMENT  (RUN  IT  ONE  MORE  TIME) 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

P  READ  (INSTRUCTIONS  FOR  TASK  2) 
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PV  RUN  (  PROG  ) 

P  COMMENT  (OK,  ONE  WORKS.  2ND  PROGRAM...) 

TASK  2 

PV  EDIT  (PROG.C) 

P  NEED  (RESULTS  IN  THE  SAME  FILE) 

PV  CHANGE  (MOVE  THE  CLOSE  DOWN,  SO  IT'S  AT  THE  END  OF  THE  PROGRAM) 

PV  INSERT  (TWO  COMMENTS) 

S  /*  1st  project  */ 

S  /*  2nd  project  */ 

P  NEED  (TO  GO  THROUGH  EACH  NUMBER  AND  CONVERT  IT) 

PV  INSERT  (FOR  LOOP) 

S  for  ( i  =  0 ;  i<20;  i  +  +)  ( 

S  ) 

TIME  0:30:00  -  TASK  2 

P  COMMENT  (DO  A  FUNCTION  TO  CONVERT) 

PV  CHANGE  (FORMAT  OF  SUM  OUTPUT  AND  ADD  A  NEWLINE) 

S  fprintf(fp,  "Array  Sum  =  %d\n\n",  sum); 

P  NEED  (TO  PRINT  INDEX  ARRAY,  DECIMAL,  AND  OCTAL) 

P  NEED  (A  HEADER  BEFORE  THIS) 

PV  PRINT  (ARRAY,  DECIMAL,  OCTAL,  INDEX,  REP,  REP,  NEW  LINE)  TO  FILE 
PV  INSERT  (COMMENT) 

S  /*  print  header  to  file  */ 

S  fprintf(fp,  "Array  \t  Decimal  \t  Octal\n", 

S  "Index  \t  Rep  \t  Rep\n"); 

PV  PRINT  (I  AND  NUMS ( I ] )  TO  SCREEN 

P  NEED  (A  FUNCTION  WHICH  RETURNS  CHARACTER  POINTER) 

PV  CHANGE  (ADD  CONVERT  TO  OCTAL  FUNCTION  TO  PRINT  STATEMENT) 

S  printf("%d  \t  %d  \t  %s\n",  i,  nums  (  i 1  ,  conv_to_octal ) ; 

PV  CHANGE  (PRINT  TO  FILE  INSTEAD  OF  TO  SCREEN) 

S  f pr int f ( f p , " %d  \t  %d  \t  %s\n" ,  i,  nums | i ) ,  conv_to_octal ) ; 

P  COMMENT  (WHOOPS,  I  NEED  TO  GIVE  THE  FUNCTION  AN  ARGUMENT) 

PV  CHANGE  (ADD  ARGUMENT  NUMS ( I ] ) 

S  f printf ( f p , " %d  \t  %d  \t  %s\n",  i,  nums ( i ) ,  conv_to_octal ( nums [ i ) ) ) 

P  INSERT  (COMMENT  ABOUT  FUNCTION) 

S  /*  convert  integer  argument  to  octal  string  */ 

PV  DECLARE  (INTEGER,  CONV  TO  OCTAL  WITH  PARAMETER  ARG ) 

PV  INSERT  (THE  FUNCTION  OUTLTNE ) 

S  int  conv_to_octa 1 ( arg ) 

S  int  arg; 

S  ( 

S  )  /*  end  of  con v_t o_oc  t a  1  */ 

PV  INSERT  (COMMENT  TO  MARK  THE  END  OF  MAIN) 

S  )  /*  end  of  main  */ 

P  NEED  (TO  TELL  IT  WHAT  THE  FUNCTION  RETURNS) 

P  COMMENT  (IF  RETURN  PTR  TO  CHAR,  HAVE  TO  GET  SPACE  FROM  SOMEPLACE) 

P  COMMENT  (MAKE  IT  AN  INTEGER) 

PV  GOTO  (OUTPUT  STATEMENT  IN  MAIN) 

PV  CHANGE  (%S  TO  %D) 

S  f print f ( fp ," %d  \t  %d  \t  %d\n",  i , nums [ i 1 , con v_t o_oct a  1 ( nums ( i  )  )  )  ; 

PV  GOTO  (CONV  TO  OCTAL  FUNCTION  DECLARATION) 

P  COMMENT  (MXKE  IT  A  DUMMY  SUBROUTINE  FOR  NOW) 

PV  INSERT  (RETURN  ITS  ARGUMENT) 

S  return  (  arg )  ; 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

TIME  0:40:00  -  TASK  |2 

PV  TYPEFILE  ( RESULT . DAT ) 

P  NEED  (TO  TAKE  OUT  SPACES  SO  OCTAL  COLUMN  WILL  LINE  UP) 
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p 


NEED  (TO  PUT  IN  AN  OCTAL  FORMAT  COLUMN  JUST  TO  CHECK  MY  ANSWERS) 


PV 

PV 

S 

s 

PV 

s 

s 

PV 

PV 

PV 

PV 

p 

PV 

p 

PV 

s 

PV 

PV 

PV 

PV 

p 

p 

F 

p 

p 

p 

PV 

P 

PV 

s 

p 

p 

PV 

s 

p 

PV 

s 

PV 

s 

s 

p 

PV 

s 

s 

TIME 

P 

PV 

PV 

s 

s 

s 

p 

p 

p 

p 

p 

p 

p 

p 


EDIT  (PROG.C) 

CHANGE  (DELETE  SPACE  BEFORE  TAB) 

fprintf(fp,  "Array  \t  Decimal\t  Octal\n”, 

"Index  \t  Rep  \t  Rep\n"); 

CHANGE  (ADD  A  COLUMN  TO  PRINT  NUMS ( I )  IN  OCTAL  FORMAT) 
fprintf(fp,"%d  \t  %d  \t  %d  \t  %  o  \  n  “  , 

i,  nums [ i  1  ,  conv_to_octal ( nuras ( i  1  )  , nums ( i ]  )  ; 

EXIT  (PROG.C) 

COMPILE  (PROG.C) 

RUN  (PROG) 

TYPE  (FILE  RESULT . DAT ) 

COMMENT  (IT  DID  OCTAL,  BUT  MY  HEADING  STILL  DIDN'T  GET  MOVED  OVER) 
EDIT  (PROG.C) 

COMMENT  (I  GUESS  IT  DOESN'T  LIKE  DOING  THE  JOINED  LINES  COMMAND) 
CHANGE  (COMBINE  THE  LINES! 

fpriniflfp,  "Array  \tDecimal\t  Octal\nIndex  \tRep  \t  Rep\n"); 
EXIT  (PROG.C) 

COMPILE  (PROG.C) 

RUN  (PROG) 

TYPEFILE  ( RESULT . DAT ) 

COMMENT  (HEADERS  LOOK  LINED  UP  NOW) 

NEED  (TO  WRITE  THE  FUNCTION) 

COMMENT  (HOW  DOES  THE  OCTAL  COMPUTATION  WORK?) 

COMMENT  (DIVIDE,  GET  A  REMAINDER,  AND  DO  IT  IN  REVERSE  ORDER) 
COMMENT  (OR  SUBTRACT  AND  GET  IT  IN  LEFT  TO  RIGHT  ORDER, 

BUT  I  HAVE  TO  KNOW  WHAT  POWER  OF  8  TO  START  ON) 

COMMENT  (DO  THE  DIVISION  METHOD) 

EDIT  (PROG.C) 

COMMENT  (START  WITH  MY  ARGUMENT) 

CHANGE  (COMMENT,  FROM  OCTAL  STRING  TO  OCTAL  INTEGER) 

/*  convert  integer  argument  to  octal  integer  * / 

NEED  (TO  KEEP  THE  NUMBER  THAT  WAS  DIVIDED  BY  8) 

COMMENT  (KEEP  MY  RESULTS  SOMEPLACE,  SO  LET'S  CALL  THAT  RESULT) 

DECLARE  (INTEGER,  RESULT) 
int  result; 

NEED  (TO  KNOW  WHAT  POWER  OF  10  PLACE  THIS  IS  GOING  TO  GO  IN) 
DECLARE  (INTEGER,  POWER_OF_TEN I 
int  power_of_10; 

INITIALIZE  (RESULT  AND  POWER_OF_TEN ) 
int  result  =  0; 
int  power  of  10  =  1; 

NEED  (TO  KEEP  DIVIDING  AS  LONG  AS  ARG  >  0) 

INSERT  (DO  WHILE  LOOP) 
do  ( 

)  while  (arg  >  0  )  ; 

0:50:00  -  TASK  #2 


NEED  (TO  GET  THE  REMAINDER  OF  ARG/8 ,  AS  WELL  AS  THE  RESULT) 
COMMENT  (THE  REMAINDER  I  CAN  GET  WITH  THE  MOD) 


CALCULATE  (RESULT,  ARG,  AND  POWER_OF_TEN ) 
result  +=  power  of_10  *  (arg  %  8); 
arg  =  arg  /  8  ; 
powe r  of  10  *=  10; 


HANDCHECK 

HANDCHECK 

HANDCHECK 

HANDCHECK 

HANDCHECK 

HANDCHECK 

HANDCHECK 

HANDCHECK 


(SO  MY  ARGUMENT  IS  937...  IF  I  MOD  THAT  BY  8  I  GET  1) 

(1  TIMES  1,  RESULT  IS  1.  THEN  MODIFY  ARG.  DIVIDE  BY  8) 
(CHANGE  POWER  OF_TEN  FOR  NEXT  TIME,  =  *  10,  EQUALS  10) 
(ARG  IS  NOW  1T7 .  DIVIDE...  MOD  OF  117  MOD  8  IS  5) 

(SO  ADD  10*5,  WHICH  IS  50,  TO  GET  THE  SECOND  DIGIT) 

(LAST  TIME...  START  WITH  14,  I  GET  6.  SO  I  ADD  600) 
(DIVIDE  14  BY  8  GET  1,  POWER  OF  TEN  BY  10  AND  GET  1000) 
(DO  MOD  AGAIN  FOR  REMAINDER  5F  I,  THE  LAST  DIGIT) 
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PV  CHANGE  (DON'T  WANT  TO  RETURN  ARG . . .  WANT  TO  RETURN  RESULT) 

S  return  ( result ) ; 

P  COMMENT  (VERIFY  ALL  VARIABLES  ARE  DEFINED  AND  INITIALIZED) 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

PV  TYPEFILE  ( RESULT . DAT ) 

P  COMMENT  (LOOKS  RIGHT.  GET  RID  OF  THE  EXTRA  COLUMN) 

PV  EDIT  (PROG.C) 

PV  CHANGE  (MOVE  OUTPUT  OF  SUM  TO  BOTTOM  OF  TASK  1) 

PV  PRINT  (MESSAGE  INDICATING  CONVERSION  IS  DONE)  TO  SCREEN 
S  printf ( "Octal  conversion  compl e t e . \n " ) ; 

P  COMMENT  (LEAVE  %0  COLUMN  IN  PRINT  TO  MAKE  SURE  I  DIDN’T  HURT  IT) 
PV  EXIT  (PROG.C) 


PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

PV  TYPEFILE  ( RESULT . DAT ) 

P  COMMENT  (OCTAL  COLUMN  STILL  MATCHES  %0  COLUMN.  LOOKS  CORRECT) 

P  NEED  (TO  GET  RID  OF  THAT  EXTRA  COLUMN  IN  THE  OUTPUT  NOW) 


PV  EDIT  (PROG.C) 

PV  CHANGE  (REMOVE  EXTRA  COLUMN  FROM  FILE  OUTPUT  STATEMENT) 

S  fprintf ( fp,  "%d  \t  %d  \t  %d\n”, 

S  i,  nuns | i] ,  conv  to  octal (nuns | i | ) ); 

PV  EXIT  (PROG.C)  ~  “ 

PV  COMPILE  (PROG.C) 

P  READ  (INSTRUCTIONS  FOR  TASK  3) 

PV  RUN  (PROG) 

PV  TYPEFILE  ( RESULT . DAT ) 

P  COMMENT  (ARRAY  SUM  AND  THREE  COLUMNS.  9  COMES  OUT  AS  11.  GOOD) 

TIME  1:00:00  -  TASK  #3 


PV  EDIT  (PROG.C) 

P  READ  (INSTRUCTIONS  FOR  TASK  3) 


PV  INSERT  (FOUR  COMMENTS  TO  AN  OUTLINE  TASK  3) 

S  /*  3rd  project  */ 

S  /*  get  number  from  terminal  */ 

S  /*  make  sure  number  between  1  and  50  */ 

S  /*  find  the  number  in  the  array  */ 

P  NEED  (TO  GET  THE  NUMBER  FROM  THE  TERMINAL) 

PV  PRINT  (PROMPT  WITHOUT  A  CARRIAGE  RETURN)  TO  SCREEN 
PV  INSERT  ( SCANF  FOR  AN  INTEGER  AND  PUT  IT  IN  NUMBER) 
S  printf (" Input  a  number  between  1  and  50:  "); 

S  scant ( "Id"  ,  tnumber); 


PV  GOTO  (TOP  DECLARATIONS) 

PV  DECLARE  (INTEGER,  NUMBER) 
S  int  number ; 


PV  GOTO  (AFTER  SCANF  CODE) 

PV  PRINT  (ECHO  INPUT  NUMBER  BACK!  TO  SCREEN) 

S  printf ( "number  =  %d\n",  number); 

P  COMMENT  (MAKE  SURE  THE  NUMBER  IS  A  GOOD  ONE) 

PV  INSERT  (IF  STATEMENT  TO  CHECK  INPUT  NUMBER) 

S  if  (number  <  1  | |  number  >  50) 

P  NEED  (TO  DO  THIS  UNTIL  THEY  ENTER  A  NUMBER  THAT'S  RIGHT) 

PV  INSERT  (A  DO  WHILE  LOOP) 

S  do  { 

S  (PREVIOUS  CODE) 

S  )  while  (number  <  1  ||  number  >  50); 

P  NEED  (TO  PRINT  A  MESSAGE  BEFORE  ASKING  THE  QUESTION  AGAIN) 

PV  PRINT  (MESSAGE  IF  THE  NUMBER  IS  OUT  OF  RANGE) 

S  printf  ("The  number  %'•  is  not  between  1  and  50\n"  .number  )  ; 

PV  CHANGE  (ADD  PARENTHESES  AROUND  FOR  AND  WHILE  CONDITIONS 
TO  OVERRIDE  DEFAULT  PRECEDENCE) 

S  if  ((number  <  1)  ||  (number  >  50)) 
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S  }  while  ((number  <  1)  ||  (number 

PV  CHANGE  (MOVE  STATEMENT  THAT  ECHOS  BACK 
TO  AFTER  DO  WHILE  LOOP) 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

P  READ  (SCREEN  -  A  NUMBER  BETWEEN  1  AND  50) 

P  TEST  (2,  IT  ACCEPTED  THAT  ONE) 

PV  TEST  (60,  TELLS  ME  IT'S  NOT  BETWEEN,  ECHOS,  AND  ASKS  ME  AGAIN) 

PV  TEST  (-1,  TELLS  ME  SAME  THING) 

P  COMMENT  (IT  WORKS  GREAT) 

TIME  1:10:00  -  TASK  #3 


>  50)); 

THE  INPUT, 


PV  EDIT  (PROG.C) 

PV  CHANGE  (ADD  AN  EXTRA  LINE  FEED  BEFORE  THE  PROMPT) 

S  printf ( "\nlnpui  a  number  between  1  and  50:  "  )  ; 

P  NEED  (TO  DO  SOMETHING  UNTIL  I  FIND  THE  NUMBER) 

P  COMMENT  (COULD  DO  A  WHILE  FOREVER,  THEN  BREAK  WHEN  I  FIND  IT) 

PV  INSERT  (WHILE  LOOP) 

S  wh lie  ( 1  )  ( 

S  ) 

P  NEED  (TO  DO  SOME  INITIALIZING) 

PV  GOTO  (ABOVE  WHILE  LOOP) 

PV  INITIALIZE  (I)  FOR  THE  ARRAY  INDEX 

S  i=10;  /  *  start  index  in  middle  of  array  */ 

PV  GOTO  (INSIDE  OF  WHILE  LOOP) 

P  NEED  (TO  COMPARE  MY  NUMBER  TO  THE  ARRAY) 

P  INSERT  (IF  STATEMENT) 

S  it  (numslil  «<«  number)  /*  found  number  -  done  */ 

P  NEED  (TO  KEEP  TRACK  OF  WHETHER  I  FOUND  IT  OR  DIDN’T  FIND  IT) 

P  READ  (INSTRUCTIONS  FOR  TASK  3) 

P  COMMENT  (I  DON'T  NEED  TO  KEEP  TRACK  OF  WHICH  ONES  IT'S  BETWEEN) 

PV  NEED  (TO  BREAK  AND  CHECK  AT  END  IF  I'VE  FOUND  IT  OR  NOT) 

PV  NEED  (TO  PRINT  HERE,  SINCE  THIS  IS  THE  ONLY  PLACE  I’M  LIKELY  TO  DECIDE  THAT 

I'VE  FOUND  THE  NUMBER) 


PV  PRINT  (FOUND  MESSAGE)  TO  SCREEN 

S  printf  ("Input  number,  %d,  found  at  array  index  %d\n " , numbe r , i  )  ; 

PV  INSERT  (BREAK  THE  LOOP  AT  THAT  POINT,  SINCE  I’M  DONE) 

S  break; 

PV  CHANGE  (ADD  BRACKETS  AROUND  STATEMENTS  UNDER  THE  IF) 

P  COMMENT  (IF  I  DIDN'T  FIND  IT,  NEED  TO  SEE  IF  IT'S  >  OR  <) 


PV  INSERT  (IF  STATEMENT) 

S  if  (nums(i|  <  number) 

P  COMMENT  (COMPARE  IT  TO  THE  LEFT  HALF) 


P 

P 

P 

P 


COMMENT 

COMMENT 

COMMENT 

COMMENT 


(A  RECURSIVE  FUNCTION  MIGHT  WORK  BETTER) 

(CALL  IT  ONCE  FROM  THE  MAIN  PROGRAM) 

(REPEAT  SEARCH,  WITH  A  NEW  START  AND  END) 

(DO  IT  FOR  THE  LEFT  HALF  OR  THE  RIGHT  HALF, 
BREAKING  IT  DOWN  UNTIL  ONLY  COMPARING  1  NUMBER) 


P  COMMENT  (MY  FUNCTION  WILL  RETURN  EITHER  A  -1  IF  IT  DOESN'T  FIND 
IT,  OR  THE  ARRAY  INDEX  IF  IT  DOES) 

PV  GOTO  (JUST  BELOW  ECHO  BACK  OF  INPUT  NUMBER) 

PV  INSERT  (I  =  BINARY  SEARCH  FUNCTION) 

PV  INSERT  (PARAMETERS:  ARRAY,  START=1,  END=20,  SEARCH  FOR  NUMBER) 

S  i  =  bin_search ( nums , 1 , 20 ,  number); 

PV  INSERT  (IF  STATEMENT  TO  CHECK  IF  NOT  FOUND) 

PV  PRINT  (NOT  FOUND  MESSAGE) 

P  COMMENT  (OTHERWISE,  I  FOUND  THE  RESULT) 

PV  PRINT  (SUCCESS  MESSAGE) 


s 

if  ( i  <  0  ) 

s 

printf! "Input 

numbe  r , 

%d. 

does  not  exist 

s 

else 

s 

printf( "Input 

numbe  r , 

%d  , 

found  at  array 
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rn  the  array. \n  "  )  ; 
index  %n\n",  number,  i  )  ; 


TIME  1:20:00 


TASK  #3 
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COMMENT  (OOPS,  DIDN'T  PUT  VARIABLE  NAME  IN  PRINT  STATEMENT  ABOVE) 
CHANGE  (ADD  THE  VARIABLE  NAME,  NUMBER) 

pr int f (" Input  number,  %d,  does  not  exist  in  the  a r r ay . \n " , numbe r ) ; 


COMMENT  (THAT'S  ALL  MAIN  NEEDS  TO  DO) 


DELETE  (GET  PID  OF  MY  ORIGINAL  LOGIC) 


DECLARE  (INTEGER  FUNCTION,  BIN_SEARCH,  WITH  PARAMETERS 

ARRAY,  START  INDEX,  STOP  INDEX,  AND  NUMBER  TO  LOOK  FOR) 
int  bin  s ea rch ( a r r ay ,  start,  stop,  target) 


DECLARE  (INTEGER  POINTER,  ARRAY) 

DECLARE  (INTEGER,  START,  STOP,  AND  TARGET) 
int  ‘array,  start,  stop,  target; 


INSERT  (COMMENT) 

/*  end  of  bin__sea  rch  V 

INSERT  (IF  STATEMENT  TO  TEST  FOR  EXIT  (NOT  FOUND)  CONDITION) 
if  (start  >  stop ) 
return  (-1); 


INSERT  (IF  STATEMENT  TO  TEST  IF  NUMBER  FOUND ) 
if  (start  ==  stop ) 
return  (start)  ; 

COMMENT  (NO,  IF  START  =  STOP,  COULD  BE  SEARCHING  AN  ARRAY  OF  1  ELEMENT) 

CHANGE  (IF  START  =  STOP  TEST  IF  TARGET  =  ARRAY [ START ) ) 

INSERT  (IF  FOUND,  CAN  RETURN  THIS  ARRAY  INDEX) 

INSERT  (ELSE  RETURN  A  -1) 

INSERT  (BRACKETS  AROUND  THAT  JUST  TO  CLARIFY  IT) 
if  (start  ==  stop)  { 

if  (target  ==  a r r ay ( s t a r t ] ) 
return( start ) ; 
else 

return  (  - 1  )  ; 

} 


COMMENT  (ELSE  I'VE  GOT  MORE  THAT  1  ARRAY  ELEMENT  TO  SEARCH) 

NEED  (TO  COMPARE  IT  TO  MIDDLE  AND  SEARCH  LEFT  OR  RIGHT  HALF) 

COMMENT  (COMPUTE  THE  MIDDLE  FIRST) 

CALCULATE  (MIDDLE  =  HALF  WAY  BETWEEN  START  AND  STOP) 
middle  =  (start  +  stop)  /  2; 

DECLARE  (INTEGER,  MIDDLE) 
int  middle; 

INSERT  (IF  STATEMENT  FOR  LESS  THAN  CASE) 

COMMENT  (WHAT  ARE  MY  ARGUMENTS  FOR  THIS  THING?) 

NEED  (TO  RETURN  SEARCH  OF  SAME  ARRAY,  SEARCHING  LEFT  HALF) 

COMMENT  (SO  START  AT  SAME  PLACE,  AND  STOP  VALUE  IS  ONE  LESS 
THAN  THE  MIDDLE  ONE,  STILL  WANT  TO  LOOK  FOR  TARGET) 
if  (target  <  a r ray ( middl e ) )  /*  search  left  half  */ 

return ( bin_search ( array ,  start,  middle-1,  target)); 

INSERT  (IF  STAEMENT  TO  TEST  IF  EQUAL  TO  ARRAY ( MI DDLE ] ) 

INSERT  (RETURN  MIDDLE) 

if  (target  ==  a r r ay [ m i ddl e j )  /*  found  target  */ 

return(middle)  ; 

1:30:00  -  TASK  #3 

COMMENT  (ELSE  IT  MUST  BE  >  MIDDLE,  SO  SEARCH  THE  RIGHT  HALF) 
COMMENT  (RIGHT  IS  SIMILAR  TO  WHAT  I  DID  IN  THE  LEFT  HALF) 

INSERT  (ELSE  START  AT  MIDDLE+1,  STOP  AT  SAME  PLACE,  SAME  NUMBER) 
else  /*  search  right  half  */ 

return  (bin  search  (  array, middle-fl,  stop,  target)); 

GOTO  (TOP  OF  BIN  SEARCH  DECLARATION) 

COMMENT  (ECHO  THE  ARGUMENTS  JUST  TO  TRACK  HOW  IT'S  GOING) 

PRINT  (START,  STOP,  AND  TARGET)  TO  SCREEN 

printf(" in  bin_search:  start=%d,  stop=%d,  target=%d\n", 
start,  slop,  target  )  ; 

COMMENT  (I'LL  TAKE  THAT  OUT  WHEN  I'M  DONE) 

EXIT  (PROG.C) 
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COMPILE  (PROG.C) 

RUN  (PROG) 

COMMENT  (LET'S  TRY  SOMETHING  THAT'S  THERE  FIRST) 

COMMENT  (THIS  WON'T  WORK.  WENT  1  TO  20.  NEED  TO  GO  FROM  0  TO  19) 

COMMENT  (LET'S  SEE  WHAT  HAPPENS  ANYWAY) 

TEST  ( ARRAY [10)  IS  27.  LET'S  SEE  IF  IT  FINDS  THAT.  IT  BLEW  UP) 

ERROR  (ACCESS  VIOLATION) 

READ  (SCREEN  -  START=1,  STOP=20,  T ARGET=  2  7 ) 

COMMENT  (LET  ME  TRY  FIXING  THE  STOP  AND  START  BEFORE  GOING  ON) 

EDIT  (PROG.C) 

CHANGE  (ON  FIRST  BIN_SEARCH  GO  FROM  0  TO  19) 
i  =  bin_search(nums,0,19 ,  number); 

EXIT  (PROG.C) 

COMPILE  (PROG.C) 

RUN  (PROG) 

TEST  (MIDDLE  IS  26,  SO  TRY  THAT  ONE.  SAME  PROBLEM) 

ERROR  (ACCESS  VIOLATION) 

READ  (SCREEN  -  START  =  0 ,  STOP=19,  TARGET=  2  6 ) 

COMMENT  (PROBLEM  BEFORE  IT  CALLS  THE  NEXT  B I N_S  E ARCH ) 

EDIT  (PROG.C) 

COMMENT  (MAYBE  IT  HAS  THE  WRONG  ARRAY) 

NEED  (TO  ADD  A  PRINT  STMT  AT  TOP  OF  THE  FUNCTION) 

PRINT  (ARRAY ( START )  AND  (STOP))  TO  SCREEN 

pr int  f ( "in  bin_search:  array ( start )«%d r  a r r ay [ s top ) «%d\n " 
array(start)  ,  array(stop); 

EXIT  (PROG.C) 

COMPILE  (PROG.C) 

ERROR  (INSERTED  A  " , "  BEFORE  IDENTIFIER  "ARRAY") 

COMMENT  (LOOKS  LIKE  A  COMMA'S  MISSING) 

EDIT  (PROG.C) 

CHANGE  (ADD  COMMA  AT  END  OF  LINE) 

printf ( "in  bin_search:  array! start J=%d,  a r r ay [ s t op ) = %d\n " , 
a r ray ( st a rt  ]  ,  array(stop); 

EXIT  (PROG.C) 

COMPILE  (PROG.C) 

ERROR  (INSERTED  A  ” ) ”  BEFORE  " , " ) 

COMMENT  (DIDN'T  HAVE  CLOSING  PAREN,  BUT  IT  COMPILED  ANYWAY) 

EDIT  (PROG.C) 

CHANGE  (ADD  CLOSING  PARENTHESIS) 
array ( start ) ,  array(stop) )  ; 

1:40:00  -  TASK  «3 

EXIT  (PROG.C) 

COMPILE  (PROG.C) 

RUN  (PROG) 

TEST  (26.  START  =  0 ,  STOP=19,  T ARGET=  2  6 .  ARRAY ( START ] « 1  ,  ARRAY ( STOP )= 5 0 ) 
ERROR  (ACCESS  VIOLATION) 

COMMENT  (GOT  THE  ARRAY  OK,  BECAUSE  IT  GOT  THE  FIRST  AND  LAST  ONE) 

COMMENT  (BUT  GOT  A  PROBLEM  BEFORE  BIN_SEARCH  THE  SECOND  TIME) 

HANDCHECK  (HAD  0,19,  AND  26.  WHAT  ARRAY  INDEX  IS  26?  26  IS  (9)) 

HANDCHECK  (THE  FIRST  ONE  I  SHOULD  LOOK  AT  IS  0+19...) 

COMMENT  (PUT  MORE  PRINTS  IN  THE  FUNCTION  TO  SEE  WHAT  IT'S  DOING) 

EDIT  (PROG.C) 

HANDCHECK  (START  IS  0,  STOP  IS  19,  AND  TARGET  IS  26) 

HANDCHECK  (START  >  STOP  IS  FALSE,  SO  IT  DOESN'T  DO  THAT) 

HANDCHECK  ( START*STOP  IS  NOT  TRUE,  SO  IT  SHOULDN'T  DO  ANY  OF  THAT) 

COMMENT  (LET'S  PRINT  MIDDLE  WHEN  WE  FIND  IT) 

PRINT  (MIDDLE)  TO  SCREEN 

pr int f ( "bin_aea rch :  middle  *  %d\n" ,  middle); 

COMMENT  (MIDDLE  SHOULD  BE  0+19  IS  19/2  IS  9.5  ROUNDS  TO  9) 

COMMENT  (SHOULD  -  ARRAY ( MI DDLE ] ,  SO  IT  SHOULD  HAVE  RETURNED  MIDDLE 
AND  EVERYTHING  SHOULD  HAVE  WORKED) 
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P  COMMENT  (SOMETHING'S  WRONG.  PUT  IN  PRINTS  TO  SEE  WHAT  IT'S  DOING) 

PV  PRINT  (IDENTIFY  WHICH  CASE  IT'S  USING)  TO  SCREEN 
S  pr  int  f  (  "  t  a  rge  t  <  a  r  r  ay  i  a.1 ddl e  ] \r. "  )  ; 

S  printf ( "target  =  a r r ay [ mi dd 1 e  ] \n  "  )  ; 

S  printf ( "target  >  a r r ay [ mi dd 1 e  | \n  "  )  ; 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

PV  TEST  (26,  IT  SET  MIDDLE  =  9,  IT  SET  TARGET  =  ... 

P  COMMENT  (FOUND  THE  EQUALS,  THEN  GOT  AN  ACCESS  VIOLATION  RETURNING) 

P  COMMENT  (LOOK  AT  WHAT  GETS  BACK,  MAY  BE  THE  WRONG  VARIABLE  TYPE) 

PV  EDIT  (PROG.C) 

P  COMMENT  (WHERE  DO  I  CALL  IT?) 

P  READ  (SOURCE  ->  SETTING  I  =  EQUAL  TO  THE  RETURN  FROM  THE  FUNCTION) 

P  COMMENT  (I  IS  AN  INTEGER  AND  FUNCTION'S  DECLARED  AS  AN  INTEGER) 

PV  PRINT  (THE  INTEGER  THAT  IS  RETURNED) 

S  printf  (  "min:  bin_search  returned  %d\n",  i  )  ; 

P  COMMENT  (OH,  I  SEE.  I'VE  GOT  A  %N  INSTEAD  OF  %D  IN  MY  PRINT) 

PV  CHANGE  (%N  TO  %D) 

S  pr int f ("  Input  number,  %d,  found  at  array  index  %d\n "  , numbe r ,  i); 

PV  EXIT  (PROG.C) 

TIME  1:50:00  -  TASK  #3 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

PV  TEST  (26,  FOUND  AT  INDEX  9.  WONDERFUL) 

P  COMMENT  (TRY  SOMETHING  THAT'S  AT  AN  END) 

PV  TEST  ( I ,  FOUND  AT  INDEX  0 ) 

P  COMMENT  (TRY  THE  RIGHT  END,  TO  MAKE  SURE  THE  >'S  WORK) 

PV  TEST  (50,  FOUND  AT  INDEX  19) 

P  COMMENT  (TRY  SOMETHING  THAT’S  NOT  THERE) 

PV  TEST  (7,  DOES  NOT  EXIST  IN  ARRAY) 

P  READ  (SCREEN  ->  CHECKING  THE  LOGIC  FLOW) 

P  COMMENT  (LOOKS  LIKE  IT  WORKS.  LET  ME  TAKE  OUT  THE  DEBUG  PRINTS) 

PV  EDIT  (PROG.C) 

PV  DELETE  (ALL  DEBUG  PRINT  STMTS,  EXCEPT  INPUT  NUMBER  ECHO  BACK) 

P  COMMENT  (LET'S  MAKE  SURE  IT  STILL  RUNS) 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

PV  TEST  (9,  FOUND  AT  INDEX  4) 

PV  TEST  (2,  DOES  NOT  EXIST  IN  THE  ARRAY) 

P  COMMENT  (PUT  ONE  MORE  CHECK  TO  MAKE  SURE  WHEN  IT'S  DONE  WITH  THE 
SEARCH  AND  SAYS  IT  FOUND  IT,  IT  REALLY  DID  FIND  IT) 

PV  EDIT  (PROG.C) 

P  COMMENT  (IF  IT  DOES  EXIST  WE  WANT  TO  MAKE  SURE  IT  REALLY  DOES) 

PV  INSERT  (IF  STATEMENT  TO  CHECK  IF  NUMBER  =  NUMS [ I ) ) 

P  COMMENT  (ELSE  I  WANT  TO  PRINT  THAT  THERE  IS  AN  ERROR  IN  MY  LOGIC) 

PV  PRINT  (ERROR  MESSAGE  AND  INDEX  RETURNED  OTHERWISE)  TO  SCREEN 
S  if  (number  ==  nums [ i ] ) 

S  pr int f ("  Input  number,  %d,  found  at  array  index  %d\n",  number,  i); 

S  else  l 

S  pr in t f (" ERROR  -  bin  search  returned  array  index  %d\n",i); 

S  printf!"  nums[%d]  is  actually  id,  should  be  %d\n", 

S  i,  nums ( i  1  ,  number): 

S  ) 

PV  COMMENT  (SO,  IF  WRONG  ANSWER  IS  RETURNED,  PROGRAM  WILL  CATCH  IT) 

PV  GOTO  (END  OF  TASK  2) 

PV  INSERT  (CLOSE  FILE) 

S  fclose  (  f  p  )  ; 

PV  DELETE  (CLOSE  FILE  STATEMENT  AT  THE  END  OF  THE  PROGRAM) 

TIME  2:00:00  -  TASK  #3 

PV  EXIT  (PROG.C) 
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P  COMMENT  (MAKE  SURE  THAT  IT  STILL  WORKS) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

PV  TEST  (26.  FOUND  AT  INDEX  9) 

P  COMMENT  (OOPS,  I  DON'T  NEED  NUMBER  =.  NEED  TO  TAKE  THAT  OUT) 
PV  TEST  (2,  DOES  NOT  EXIST  IN  ARRAY) 

PV  EDIT  (PROG.C) 

PV  DELETE  (PRINT  THAI  ECHOED  BACK  THE  INPUT  NUMBER) 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG.C) 

P  READ  (SCREEN  -  NUMBER  BETWEEN  1  AND  50) 

PV  TEST  (55,  NOT  BETWEEN  1  AND  50) 

PV  TEST  (-4,  NOT  BETWEEN  1  AND  50) 


p 

COMMENT 

(NUMBERS 

TOO 

BIG  OR 

TOO 

SMALL  -  STILL  PICKS  THEM  OUT) 

p 

TEST  (1, 

,  roUND. 

50  , 

FOUND . 

34  , 

,  NOT  THERE) 

p 

COMMENT 

(I  THINK 

I  'M 

DONE  ) 
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SUBJECT  #2  FINAL  PROGRAM 


•include  <«tdio.h> 
main ( ) 

/*  Thi*  program  initialises  array  of  integers.  */ 

l 

ri LB  *  f  p ; 
lnt  1,  aum-0; 
int  number; 

lnt  null [ 20 )  -  {1,3,5,1,9,12,13,19,29,26,27,29,33,35,11,39,40,43,49,90); 
printf  ( "Tha  HUMS  array  haa  baan  initialised. Sn"  )  ; 

/*  lat  project  */ 

/*  iua  tha  array  elements  */ 
for  (1-0;  i <  2  0  ;  i++)  ( 
iui  +■  nuns l i  ] ; 

) 

/*  write  tha  raault  to  a  file  */ 
fp  -  f open (" raault . dat " ,  "w+" ) ; 
fprintf(fp,  "Array  Sum  -  td\n\n",  aum); 
printf("The  aum  of  tha  MUMS  array  la  4d\n",  aum); 

/*  2nd  project  */ 

/*  print  header  to  file  */ 

fprlntflfp,  "Array  \tDacimal\t  Octal\nZndax  \tRap  \t  RepSn"  )  ; 
for  (i-0;  i <  2  0  ;  1++)  ( 

f printf ( fp ,” %d  \t  %d  St  %dsn" ,  i,  numa(i),  conv  to  octal (numa 1 1 ] ) ) ; 

)  “  “ 
fcloaa  (fp); 

printf ( "Octal  convaraion  complete <Sn" ) j 

/*  3rd  project  */ 
do  ( 

/*  gat  number  from  terminal  */ 

printf ( "Snlnput  a  number  between  1  and  90;  "); 

aeanf(”%d",  (number) ; 

/*  make  aura  number  between  1  and  90  */ 
if  ((number  <  1)  ||  (number  >  90)1 

printf  ("The  number  %d  la  not  between  1  and  90Sn" , number ) ; 

]  while  ((number  <  1)  ||  (number  >  90)); 

/*  find  the  number  in  array  */ 

1  ■  bin  aea rch ( numa , 0 , 19  ,  number); 
if  (i  <“0) 

printf ( "Input  number,  %d,  doea  not  exiet  in  the  array  An" , number ) ; 

else  ] 

It  (number  «  numa(l)) 

printf ( "Input  number,  Id,  found  at  array  index  tdsn",  number,  i); 

else  { 

printf ( "ERROR  -  bln  aearch  returned  array  index  %dSn”,i); 

printf!”  numT(%d]  la  actually  4d,  should  be  tdSn",  1 , numa ( 1 ], number ) ; 

) 

) 

)  /*  end  of  main  */ 

int  bln  aearchlarray ,  start,  stop,  target! 
lnt  "arTay,  atart,  atop,  target; 

( 

lnt  middle; 
if  (start  >  stop) 
return  (-1); 
if  (atart  ■■  atop)  ( 

if  (target  »  ar ray ( start ] ) 
return ( atart ) ; 

else 

return  (-1); 

) 

middle  ■  (atart  *  atop)  /  2; 

it  (target  <  array (middle )) (  /*  search  left  half  */ 

retu rn ( bin_aea rch ( a r ray ,  atart,  middle-1,  target)); 

If  (target  ■■  array (middle ] )  {  /*  found  target  V 

return ( middle ) ; 

)  else  (  /*  aearch  right  half  */ 

return(bln  aearchlarray ,mlddle+l ,  stop,  target)); 

} 

)  /*  end  of  bln  search  */ 
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/  convert  integer  argument  to  octal  integer  */ 
int  conv_t o_oc t a  1 ( a r g  ) 
i  n  t  a  r  g  ; 

( 

int  result  =  0; 
int  power  of  10  *  1; 
do  (  -  - 

result  +=  power  of  10  *  (arg  %  8); 
arg  «  arg  /  8;  ~ 

power  of_10  *=  10; 

)  while  (arg  >  0); 
return) result  )  ; 

)  /*  end  of  conv  to  octal  */ 
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SUBJECT  #3  DATA 


TIME 

PV 

P 

P 

P 

PV 


PV 

PV 

PV 

s 

s 

s 

s 

p 

PV 

PV 

PV 

s 

s 

PV 

PV 

s 

s 

PV 

s 

p 

PV 

s 

p 

p 

p 

PV 

s 

PV 

PV 

PV 

PV 

PV 

P 

P 

p 

TASK 

P 

P 

PV 

p 

s 

TIME 

P 

P 

P 

PV 

PV 

s 

PV 

PV 


0:00:00  -  TASK  |1 

EDIT  (PROG.C) 

READ  (INSTRUCTIONS  FOR  TASK  1) 

NEED  (TO  PUT  IN  SOME  VARIABLES) 

COMMENT  (FIRST  GET  MY  FILE  READY) 

DECLARE  (FILE  POINTER,  FP ) 

FILE  *  f  p ; 

INSERT  (OPEN  FILE,  FILE. OUT,  IN  WRITE  MODE) 
INSERT  (TEST  FOR  ERRORS  WHEN  OPENING  THE  FILE) 
INSERT  (ON  ERROR,  EXIT) 

if  (  (fp  =  f open (" file . out  ", "w" )  )  ==  -1))  { 

po r  ro  r ( " f open "  )  ; 
e  x  i  t  (  - 1  )  ; 

} 


COMMENT  (NOW  SET  UP  MY  PROGRAM) 

DECLARE  (INTEGER,  I)  TO  INDEX  THROUGH  MY  ARRAY 
DECLARE  (INTEGER,  SUM)  WHERE  I  ADD  THEM  UP 
INITIALIZE  (SUM  IN  THE  DECLARATION) 
i nt  i  ,  sum*=0  , 

nums [20]*{1, 3, 5, 8, 9, 12, 13, 19, 25, 26, 27, 29, 33, 35, 38, 39, 40, 43, 45, 50); 

INSERT  (FOR  LOOP) 

CALCULATE  (SUM) 

f or ( i=0 ; i <20 ) ? i++ ) 

sum  +=  nums [ i ) ; 

PRINT  (SUM)  TO  FILE 

f print f ( fp , "The  sum  of  all  the  numbers  is:  %d . \n " , sum ) ; 

COMMENT  (I  FORGOT  THE  LINE  FEEDS) 

CHANGE  (ADD  SEVERAL  NEWLINES) 

f print f ( fp , "\n\n\nThe  sum  of  all  the  numbers  is:  %d . \n " , sum ) ; 

COMMENT  (OUTPUT  FILE  SHOULD  CLOSE  AUTOMATICALLY) 

READ  (CODE,  TO  MAKE  SURE  LOGIC  LOOKS  OK) 

COMMENT  (I  HAVE  A  TYPO  ON  MY  FOR  LOOP) 

CHANGE  (DELETE  BRACKET) 

f or ( i«0 ; i <  20 ; i++ ) 

EXIT  (PROG.C) 

COMPILE  (PROG.C) 

ERROR  (UNEXPECTED  ")"  IGNORED) 

RUN  ( PROG ) 

TYPEFILE  (FILE. OUT) 

COMMENT  (IT  GOT  500) 

HANDCHECK  (ADD  ARRAY  NUMBERS  ON  THE  CALCULATOR) 

COMMENT  (LOW  AND  BE*»OLD:  50  0) 

2 

READ  (INSTRUCTIONS  FOR  TASK  2) 

COMMENT  (I  WILL  USE  THE  DIVISION  TECHNIQUE ) 

EDIT  (PROG.C) 

CHANGE  (COMMENT  OUT  LINES  THAT  PRINTED  THE  SUM) 

/*  f print f ( fp , "\n\n\nThe  sum  of  all  the  numbers  is:  %d.\n",sum);  V 

0:10:00  -  TASK  #2 

COMMENT  (SHOULD  I  USE  A  STRING  ARRAY  TO  STORE  MY  VALUES?) 

COMMENT  (WHILE  I'M  THINKING,  I'M  GOING  TO  FORMAT  MY  OUTPUT) 

NEED  (TO  LEAVE  THE  ARRAY  SUM  IN  THERE) 

CHANGE  (DELETE  COMMENTS  MARKERS  AROUND  SUM  OUTPUT) 

CHANGE  (ADD  MORE  LINE  FEEDS  AT  END  OF  PRINT) 

f pr int f ( f p , "\n\n\nThe  sum  of  all  the  numbers  is:  %d . \n\n\n " , sum ) ; 

PRINT  (ARRAY,  DECIMAL,  OCTAL,  LINEFEED)  TO  FILE 
PRINT  (INDEX,  REP,  REP,  2  LINE  FEED)  TO  FILE 
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fprintf ( fp, "Array  Daciaal  Octal\n"); 

f print f ( fp Index  Rep  Rap\n\n"); 

COMMENT  (I'LL  CALCULATE  THE  THINGS  AS  I  PRINT  THEM  OUT) 

COMMENT  ( WHAT  VARIABLES  DO  !  NEED?) 

COMMENT  (ALL  NUMBERS  ARE  2  DIOITS,  SO  JUST  MAKE  IT  2  CHARACTERS) 

COMMENT  (COUNT  OFF  TO  OET  APPROXIMATELY  WHERE  I  NEED  TO  BE) 

COMMENT  (I  MIGHT  HAVE  SOME  THAT  ARE  3  LONG ) 

COMMENT  (SO  DECIMAL  IS  62  OCTAL,  SO  I  JUST  NEED  2) 

V  PRINT  (DECIMAL,  DECIMAL)  TO  FILE 

f prlntf ( fp , "  %2d  %2d\n " , i , numi ( i  )  )  ; 

NEED  (TO  FIGURE  OUT  MY  OCTAL  REPRESENTATION) 

COMMENT  (I  COULD  PUT  IT  IN  A  STRING) 

COMMENT  (PUT  NUMBER  MOD  6  AS  MY  FIRST  CHARACTER) 

COMMENT  (IF  I  USE  THIS  TECHNIQUE,  KEEP  INCREMENTING  CHARACTER  COUNT,  MAKE  A  SMALL 

ARRAY,  AND  KEEP  DOING  MODS.  SAVE  RESULT  AND  REMAINDER,  PUT  REMAINDER  IN  A 
CHARACTER,  BUMP  CHARACTER  OVER  1  AND  DIVIDE  AND  JUST  KEEP  THE  DIVIDING) 

COMMENT  (PUT  IT  INTO  A  STRING,  OR  DO  THIS  IS  BY  SHIFTING) 

COMMENT  (USE  A  CHARACTER  STRING) 

V  CHANGE  (ADD  STRINO  TO  OUTPUT  STATEMENT) 

fprintf(fp,"  %  2d  %2d  %s\n" , i , nuns [ 1 ] , at r  )  ; 

NEED  (TO  REMEMBER  TO  NULL  TERMINATE  MY  STRING) 

READ  (INSTRUCTIONS  FOR  TASK  2) 

COMMENT  (937  IS  1651  OCTAL.  THE  6  WOULD  00  FIRST) 

COMMENT  (SO  IF  I  BUMP  MY  CHARACTERS...) 

COMMENT  (DO  A  MOD  8  FIRST  TO  GET  THE  LEAST  DIGIT) 

COMEMNT  (DO  IT  WITH  A  CHARACTER  STRING) 

COMMENT  (CONVERT  AND  CONCATENATE  VALUES  ONTO  END  OF  STRING) 

COMMENT  (THAT  WOULD  WORK) 

NEED  (TO  SAVE  THIS  TO  A  STRING) 

V  DECLARE  (CHARACTER  ARRAY  OF  10,  STR ) 

char  atrllO]; 

NEED  (ANOTHER  CHARACTER  STRING) 

COMMENT  (PROBABLY  2  IS  ALL  WE'LL  NEED...) 

V  DECLARE  (CHARACTER  ARRAY  OF  2,  TMP ) 

char  atr [ 10 ) , tap( 2  ) ; 

XMI  Os  20: 00  -  TANK  02 

V  INSERT  (FOR  LOOP  AROUND  PRINT  STATEMENT) 

for  (i»0;  i <  2  0 :  1  +  + )  ( 

) 

COMMENT  (HOW  SHOULD  I  DO  IT7 ) 

NEED  (A  COUPLE  MORE  VARIABLES) 

V  GOTO  (DECLARATIONS) 

V  DECLARE  (INTEGER,  J) 

int  i,J,»u««0, 

nu»i (20]a(l, 3, 5, 6, 9, 12, 13, 19, 25, 26, 27, 29, 33, 35, 36, 39, 40, 43, 45, 50); 

V  OOTO  (INSIDE  FOR  LOOP) 

V  CALCULATE  (J) 

j  ■  nuai l 1 J  %  6 ; 

V  INSERT  (READ  INPUT  INTO  TMP) 

aprintf ( tap, "»d" , J ) ; 

COMMENT  (THIS  GIVES  ME  THE  LEAST  SIGNIFICANT  DIGIT) 

COMMENT  (KEEP  CATTING  THE  NUMBER  ONTO  THE  END  OF  WHAT  I  OET) 

V  INITIALIZE  (STR)  TO  NULL  TERMINATE  IT 

atr ( 0  J  ■  '\0'; 

V  INSERT  (STRINO  CONCATENATE  TEMP  ON  END  OF  STRING) 

at rcat ( at r , tap ) ; 

V  INSERT  (WHILE  LOOP) 

whila  (j  »  )  ( 
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COMMENT  (IF  I  MAKE  IT  >  0 ,  WILL  THAT  LAST  CASE  WOULD  OET  DONE?) 

COMMENT  (NOT  SURE  WHAT  A  MOD  WILL  DO  WHEN  A  NUMBER  IS  LESS  THAN  S) 

CHANGE  (CONDITION  IN  WHILE  LOOP) 
whil#  (j  >  7)  ( 

) 

COMMENT  (TAKE  IT  AS  A  SPECIAL  CASE  TOR  NOW) 

GOTO  (INSIDE  WHILE  LOOP! 

CALCULATE  ( J ) 

j  «  nuabtr  %  8; 

COMMENT  (THIS  ISN'T  OOING  TO  WORK) 

GOTO  (ABOVE  WHILE  LOOP) 

INITIALIZE  (J) 
j  -  nuai  [  1 ] ; 

GOTO  (INSIDE  WHILE  LOOP) 

CHANGE  (0  CALCULATION) 

j  -  j%«? 

NEED  (TO  RUN  THIS  PROGRAM  AND  SEE  WHAT  IT  RETURNS) 

COMMENT  (IN  LAST  CASE,  MIGHT  HAVE  TO  DUPLICATE  THESE  LIMES) 

COMMENT  (COULD  DO  IT  INSIDE  THE  LOOP  AND  BREAK  OUT  OF  THE  LOOP  THEN  JUST  CHECK 
DOWN  AT  THE  BOTTOM) 

COMMENT  (IF  J  <  8  THEN  I  TOOK  CARE  OF  THE  LAST  TIME  AND  NOT  MAKE  J  GO  AROUND  AGAIN) 
COMMENT  (THAT  WOULD  WORK,  BUT  THIS  SHOULD  GET  ME  ALMOST  DONE ) 

EXIT  (PROO.C) 

COMPILE  (PROO.C) 

COMMENT  (SEE  IF  I'VE  MADE  ANY  TYPOS) 

ERROR  (UNEXPECTED  " ) "  IGNORED) 

ERROR  (TMP  NOT  DECLARED  WITHIN  SCOPE  OF  THIS  USAGE) 

ERROR  (STR  NOT  DECLARED  WITHIN  SCOPE  OF  THIS  USAGE) 

ERROR  (FOUND  " : "  WHEN  EXPECTING  ARITHMETIC  OPERATOR) 

EDIT  (PROO.C) 

CHANGE  (MOVE  CHARACTER  DECLARATIONS  ABOVE  FIRST  PRINT  STMT) 

CHANGE  (DECLARATION  OF  TMP  TO  ARRAY  OF  J) 
char  atr[10],  tap[3|; 

READ  (MANUAL  ON  STRING  CAT) 

NEED  (TO  SEE  WHETHER  I  NEED  TO  INCLUDE  A  . H  FILE  HERE) 

COMMENT  (DOESN'T  LOOK  I  NEED  ANY  SPECIAL  INCLUDE  FILE  FOR  STRING  CAT) 

EXIT  (PROO.C) 

COMPILE  (PROO.C) 

ERROR  (UNEXPECTED  " ) "  IGNORED) 

ERROR  (FOUND  " : "  WHEN  EXPECTING  ARITHMETIC  OPERATOR) 

EDIT  (PROO.C) 

GOTO  (INSIDE  FOR  LOOP) 

COMKENT  (PUT  A  COLON  WHERE  I  NEED  A  SEMICOLON) 

CHANGE  (:  AFTER  I<20  TO  ;  ) 
for  (i-0;  i<20;  i++) 

0:30:00  -  TASK  02 

EXIT  (PROO.C) 

COMPILE  (PROO.C) 

ERROR  (UNEXPECTED  " ) "  IGNORED) 

RUN  (PROO) 

TYPEFILE  (FILE. OUT) 

NEED  (TO  RE- INITIALIZE  MY  STRING  EACH  TIME) 

COMMENT  (THE  LAST  DIGIT  IS  GETTING  TAKEN  CARE  OF) 

COMMENT  (I  THINK  THIS  IS  OONNA  WORK) 

EDIT  (PROO.C) 

CHANOE  (MOVE  STR  INITIALIZATION  INSIDE  FOR  LOOP) 
for  (i-0;  i  <  20 ;  i*-+)  ( 
at r ( 0  )  -  '\0 ' ; 

COMMENT  (BACK  TO  THE  PROBLEM  OF  THE  LAST  LINE  TYPE  ERROR) 
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PV  CHANGE  (WHILE  LOOP  CONDITION  SO  IT  LOOPS  FOREVER) 

S  while  (1)  ( 

S  ) 

PV  GOTO  (END  OF  WHILE  LOOP) 

PV  INSERT  (IF  STATEMENT  FOR  SPECIAL  CASE) 

S  if  ( j  <  8 ) 

S  break; 

P  READ  (MANUAL  ON  BREAK) 

P  COMMENT  (NO... I 'LL  DO  IT  ANOTHER  WAY) 

PV  CHANGE  (IF  STATEMENT  SET  J=0  INSTEAD  OF  BREAK-ING) 

S  if  ( j  <  8 ) 

S  j  =  0  ; 

P  COMMENT  (CHECK  FOR  J  =  0) 

PV  CHANGE  (WHILE  LOOP  CONDITION  FROM  FOREVER) 

S  while  ( j  !=  0  )  ( 

PV  EXIT  (PROG.C) 

P  COMMENT  (ONCE  I  GET  CLOSE,  I  USE  TRIAL  AND  ERROR) 

PV  COMPILE  (PROG.C) 

PV  ERROR  (UNEXPECTED  " ) "  IGNORED) 

P  ERROR  (I  FORGOT  TO  FIX  THAT  ONE  WARNING) 

PV  RUN  (PROG) 

PV  TYPEFILE  (FILE. OUT) 

P  COMMENT  (I'M  STILL  OFF  BY  ONE.  I'M  MISSING  MY  FIRST  CHARACTER) 

P  COMMENT  (MY  STRING  CONCAT  IS  NOT  WORKING) 

P  HANDCHECK  (CONVERT  ON  CALCULATOR  TO  MAKE  SURE  LAST  NUMBERS  ARE  CORRECT) 

P  HANDCHECK  (25  SHOULD  BE  1.  THAT'S  CORRECT) 

P  HANDCHECK  (26  SHOULD  BE  2.  OK) 

P  COMMENT  (I'M  JUST  MISSING  THE  FIRST  CHARACTER) 

PV  EDIT  (PROG.C) 

P  NEED  (TO  FIGURE  OUT  WHAT  J  MOD  0  IS  GONNA  GET  ME) 

P  COMMENT  (I  THINK  A  MOD  IS  GONNA  GIVE  ME  0) 

PV  DELETE  (IF  STATEMENT  THAT  SETS  J  TO  ZERO) 

P  HANDCHECK  (FIRST  TIME  THROUGH,  FOR  1  IT  WOULD  GET  1  AND  IT  WOULD  GO  THROUGH  AND 

J  .  .  .  ) 


P  COMMENT  (LOOKING  AT  THE  MOD.  I  NEED  THE  ACTUAL  RESULT  ALSO) 

P  NEED  (ANOTHER  VARIABLE/ 

PV  DECLARE  (INTEGER,  MODI 

PV  DELETE  (DECLARATION  OF  J) 

PV  DECLARE  (INTEGER,  DIV) 

S  int  i , mod , di v , s um= 0  , 

S  nuns [20]  =  (1,3,5,8,9,12,13,19,25,26,27,29,33,35,38,39,40,43,45,50); 

PV  GOTO  (INITIALIZATION  OF  J,  ABOVE  WHILE  LOOP) 

PV  CHANGE  (USE  DIV  IN  PLACE  OF  Jl 
S  div=nums[i); 


PV  CHANGE  (WHILE  CONDITION  TO  USE  DIV  INSTEAD  OF  J) 
S  while  ( di v  ! =  0  )  { 

PV  GOTO  (INSIDE  WHILE  LOOP) 

PV  CHANGE  (USE  DIV  INSTEAD  OF  J  IN  J  CALCULATION) 

S  j  =  d  i  v  %  8  ; 

PV  GOTO  (END  OF  WHILE  LOOP) 

PV  CALCULATE  (DIV) 

S  div  /=  8; 


P  COMMENT  (FIND  REMAINDER  AND  GET  THE  VALUE) 


PV  CHANGE  (WHILE  CONDITION  FROM  ! =  TO  >) 
S  while  (div  >  0)  { 


P  COMMENT  (IF  THIS  DOESN'T  WORK,  I'LL  ADD  PRINT  STATEMENTS 

TO  SEE  HOW  MANY  TIMES  I'M  LOOPING  AND  WHAT  MY  VALUES  ARE) 
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PV 

EXIT  (PROG.C) 

PV 

COMPILE  (PROG.C) 

PV 

ERROR  (UNEXPECTED  ")"  IGNORED) 

PV 

ERROR  (J  NOT  DECLARED  WITHIN  THE 

SCOPE  OF  THIS  USAGE) 

p 

NEED  (TO  CHANGE  ALL  MY  TERMS  WITH 

A  J  TO  BE  MOD) 

PV 

EDIT  (PROG.C) 

PV 

CHANGE  (J'S  TO  MOD'S) 

s 

mod  =  div%8; 

s 

sprintfltmp, "%d" ,mod) ; 

PV 

EXIT  (PROG.C) 

TIME 

0:40:00  -  TASK  «2 

PV 

COMPILE  (PROG.C) 

PV 

ERROR  (UNEXPECTED  " ) "  IGNORED) 

p 

COMMENT  (STILL  HAVE  TO  TAKE  CARE 

OF  PARENTHESES  PROBLEM) 

PV 

RUN  (PROG) 

PV 

TYPEFILE  (FILE. OUT) 

P  COMMENT  (THE  NUMBERS  ARE  RIGHT,  I  JUST  HAVE  THEM  BACKWARD) 

P  COMMENT  (I  JUST  DID  MY  CON  CAT  WRONG) 

P  COMMENT  (CHECK  THEM  EVEN  THOUGH  THEY'RE  BACKWARDS) 

P  HANDCHECK  (50  IN  OCTAL  IS  62) 

PV  EDIT  tPROG.C) 

P  COMMENT  (MAYBE  IT'S  NOT  EVEN  A  STRING  CAT  I  WANT  TO  DO) 

PV  CHANGE  (SWITCH  ORDER  OF  STR  AND  TMP ,  TO  PUT  STRING  ON  END  OF  TEMP) 

PV  INSERT  (THEN  COPY  TEMP  RIGHT  BACK  INTO  STRING,  TO  SWAP  IT  AROUND) 

S  st  rest ( tmp , s  t  r )  ; 

S  strepy ( str , tmp ) ; 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  ERROR  (UNEXPECTED  ">"  IGNORED) 

PV  RUN  (PROG.C) 

PV  TYPEFILE  (FILE. OUT) 

P  COMMENT  (LOOKS  GOOD) 

P  HANDCHECK  (CONVERSIONS) 

P  COMMENT  (PART  B  IS  DONE) 

TASK  3 

P  READ  (INSTRUCTIONS  FOR  TASK  3) 

PV  EDIT  (PROG.C) 

P  CHANGE  (COMMENT  OUT  THE  STUFF  WE'VE  DONE  SO  FAR) 

S  /♦  for(i=0;i<20;i++) 

S  (CODE  FOR  TASKS  1  AND  2) 

S  */ 

PV  GOTO  (TOP  OF  PROGRAM) 

P  NEED  (TO  PROMPT  THE  USER) 

P  READ  (INSTRUCTIONS) 

PV  INSERT  (PROMPT) 

S  pr intf ( "\n\nPlease  enter  a  number  between  1  and  50:"); 

PV  INSERT  (READ  INPUT  NUMBER  AND  THE  CARRIAGE  RETURN) 

S  gets(str); 

PV  INSERT  (PUT  INTEGER  PART  OF  INPUT  IN  VARIABLE  I) 

S  sscanf(str,"%d",ti); 

P  READ  (INSTRUCTIONS  FOR  TASK  3) 

P  NEED  (AN  INDEX) 

PV  GOTO  (DECLARATIONS) 

PV  DECLARE  (INTEGER,  INDEX) 

PV  INITIALIZE  (INDEXI 

S  int  i, index  =  0 , mod , d i v , sum=0 , 

S  nums (20)  =  (1,3,5,8,9,12,13,19,25,26,27,29,33,35,38,39,40,43,45,50} 

PV  GOTO  (AFTER  INPUT  CODE) 

P  COMMENT  (ASSUME  IT'S  BETWEEN  0  AND  50) 

P  COMMENT  (NOW  LET'S  SEE  IF  I  CAN  FIND  IT) 

PV  NEED  (TO  COMPARE  NUMBER  TO  THE  MIDDLE  ENTRY  IN  THE  ARRAY) 
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NEED  (TO  BE  IN  A  LOOP) 

READ  ( INSTRUCTIONS  POR  TASK  3) 

COMMENT  (HOW  WILL  X  KNOW  THAT  X'M  DONE?) 

COMMENT  ( XEEP  AN  INDEX ) 

COMMENT  (IP  IT  WAS  >,  THEN  CHECK  BETWEEN  10  AND  20) 

COMMENT  (HOW  AM  X  OONNA  KNOW  THE  DXPPERENCE? ) 

NEED  (TO  ADD  HALP  THE  NUMBER  OR  SUBTRACT  HALP  THE  NUMBER...) 
HAHDCHECK  (IP  XT  WAS  >  10,  TAKE  HALP  OP  10,  AND  ADD  XT  TO  OET  15) 
HANDCHECK  (IP  XT  WAS  <  10,  TAKE  HALP  OP  10,  IS  5,  AND  SUBTRACT  XT) 
HAHDCHECK  (NOW  CHECK  THE  5.  FOLLOW  XT  ONE  MORE  STEP  FURTHER ) 

HANDCHECK  (IP  X  HAD  PICKED  10  AND  XT  WAS  HIGHER  NOW  X  PXCK  15) 
HANDCHECK  (NOW  IP  XT  WAS  S TILL  HIGHER,  TAKE  HALP  THAT  NUMBER) 
COMMENT  (NO  THAT  WOULDN'T  WORK...) 

INI  OlBOlOO  -  TASK  »J 

COMMENT  (TAKE  DIFFERENCE  OP  THE  NUMBERS  AND  HALP  THAT  NUMBER...) 
HANDCHECK  (20  AND  10.  DXPPERENCE  AND  HALP  XT  WOULD  BE  15) 

COMMENT  (SO  I  KNOW  IT'S  EITHER  ADDED  OR  SUBTRACTED) 

COMMENT  (IP  X  ADDED  ONE  STEP  FURTHER...) 

HANDCHECK  (DIPP  BETWEEN  15  AND  10,  DIVIDED  BY  2,  X  WOULD  GET  2, 

SO  X  WOULD  CHECK  + 2  OR  -2) 


NEED  (TO  USE  PENCIL  AND  PAPER  AND  FOLLOW  THROUGH  THE  INDEXES) 

HANDCHECK  (USE  ALL  THE  NUMBERS  BETWEEN  1  AND  12) 

HANDCHECK  (FIRST  TIME,  INDEX  -  TOTAL  NUMBER  -  12) 

HANDCHECK  (CHECK  6.  SAY  X'M  LOOKING  POR  THE  NUMBER  10) 

HANDCHECK  (INDEX! 6]  -6.  X  CHECK  MY  TARGET  AND  XT'S  >) 

HANDCHECK  (SO  NUMBER'S  BETWEEN  INDEX! 6]  AND  [1]) 

HANDCHECK  (INDEXES  GO  PROM  0  TO  11) 

HANDCHECK  (XP  X  TOOK  DXPPERENCE  OP  LAST  TWO  NUMBERS...) 

HANDCHECK  (DXPPERENCE  WOULD  BE  5/2,  GIVES  ME  2 .  SO  I'D  ADD  2) 

HANDCHECK  (NOW  CHECK  S.  NO ,  S ' S  NOT  RIGHT) 

COMMENT  (XP  X  WANT  TO  GO  BETWEEN  t  AND  S ,  DO  X  WANT  TO  CHECK  BETWEEN  6  AND  S?) 


HANDCHECK  (FIRST  TIME  X'D  BE  ON  6.  THEN  3,  THEN  PROBABLY  1) 
COMMENT  (ASSUME  X  DIVIDE,  XT  WILL  BE  A  FACTOR  OP  2  EACH  TIME) 
HANDCHECK  (FIRST  TIME  LOOK  AT  6 .  XP  XT  WAS  ABOVE  6,  ADD  3) 
HANDCHECK  (IP  XT  WAS  ABOVE  AGAIN ,  ADD  1) 

HANDCHECK  (XP  THAT  WASN'T  IT,  THEN  THAT  WOULDN'T  HAVE  WORKED) 


COMMENT  (TRY  A  DIFFERENT  SCENARIO) 

HANDCHECK  (WE  HAVE  12  ENTRIES.  LOOKING  POR  THE  NUMBER  6) 
HANDCHECK  (NEED  TO  INDEX  OUR  VALUE.  XT  EQUALS  THE  NUMBER/2  -  1) 
HANDCHECK  (THAT  GIVES  ME  5  AS  MY  FIRST  VALUE) 


READ  (INSTRUCTIONS  POX  TASK  3) 

COMMENT  (I'M  GONNA  HAVE  TO  FIGURE  OUT  AN  ALGORITHM) 

COMMENT  (PROBLEM  IS  THAT  YOU  GET  DOWN  TO  BETWEEN  2  OR  3  NUMBERS, 
AND  THERE'S  3  NUMBERS  IN  BETWEEN.  SUBTRACT  2  OR  1?) 


COMMENT  (THIS  NEEDS  TO  BE  WELL  THOUGHT  OUT  BEFORE  I  START) 
COMMENT  (SOMETIMES  XT  HELPS  TO  THINK  OP  SOMETHING  ELSE) 


XME  1 1 00  S  00  -  TASK  #3 


HANDCHECK  (WRITE  TEST  LIST  ON  PAPER) 

HANDCHECK  (GO  PROM  1  TO  19.  LOOK  POR  4) 

HANDCHECK  (GOES  OUT  TO  10,  AND  GETS  15.  IT'S  <) 

HANDCHECK  (INDEX  -  10  -  10/2.  SO  INDEX  ■  5) 

HANDCHECK  (CHECK  5.  IT'S  <  5.  SO  XNDBX-INDEX-XNDBX/2 .  WILL  BE  3) 
HANDCHECK  (CHECK  3.  IT'S  STILL  <5.  I'M  GONNA  SAY...) 

COMMENT  (WAIT,  XT  SHOULD  BE  (INDEX  *  l)/2,..) 

HANDCHECK  (INDEX  -  10.  INDEX  -  ((INDEX  *  l>/2)  WOULD  GIVE  US  5) 
HANDCHECK  (THEN  S-<6/2)  WILL  GIVE  ME  3 .  SO  CHECK  3) 

HANDCHECK  (NEXT  TIME  SAY  3- (4/2).  SO  CHECK  1) 

HANDCHECK  (THEN  l-(2/2).  GOT  0,  SO  THAT  WOULDN'T  WORK) 

COMMENT  (CHECK  XP  THERE'S  A  DIFFERENCE  OP  1  BETWEEN  THE  NUMBERS?) 

HANDCHECK  (FIRST  TIME  INDEX  •  10.  20-(20+l)/2  GETS  10) 

HANDCHECK  (LOOK  AT  10,  NUMBER  WE'RE  LOOKINO  POR  IS  <) 

HANDCHECK  (SO  INDEX-INDEX- (( INDEX  +l)/2).  OET  INDEX  OP  5) 
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P  HANDCHECK  (LOOK  AT  5.  IT'S  HIGHER  THAN  5.  SO  IT'S  5+( (5+l)/2)) 

P  HANDCHECK  (LOOK  AT  8.  IT'S  LOWER  THAN  8.  THIS  ISN'T  GONNA  WORK...) 

P  NEED  (TO  KEEP  TRACK  OF  OLD  INDEX.  OLD  HIGH  AND  OLD  LOW...) 

P  HANDCHECK  (FIRST  CASE:  LOW  =  0,  HIGH  =  19,  MIDDLE  =  10) 

P  HANDCHECK  (IF  IT'S  HIGHER,  LOW=10,  HIC,H=20,  MI DDLE= ( 10+19 )  /  2  =  1  4 ) 

P  HANDCHECK  (IF  IT'S  >,  WE  CAN  KEEP  GOING  UNTIL  LOW  =  HIGH) 

P  HANDCHECK  (WRITE  #'S  ON  PAPER  FOR  HAND  CALCULATIONS.  LOOK  FOR  13) 

P  HANDCHECK  (LOW  =  0,  HIGH  =  19.  (0  +  1 9 )/2 . . . START  ON  9) 

P  HANDCHECK  (LOOK  AT  9.  >  9,  SO  LOW=9,  HIGH=19,  MI D= 1 9+ 9/2= 2 8/2=1 4 ) 

P  HANDCHECK  (LOOK  AT  1 4 .  <  14,  SO  HIGH=14,  LOW  STAYS  9,  AND  MID=11) 

P  HANDCHECK  (LOOK  AT  11.  >  11,  SO  LOW=ll,  HIGH  STAYS  1 4 , MI D= 2 5/2=1 2 ) 

P  HANDCHECK  (LOOK  AT  12.  >  12,  SO  LOW=12,  HIGH  STAYS  14,  MID=13) 

P  COMMENT  (WE  HAVE  FOUND  OUR  ANSWER) 

P  COMMENT  (LOOKS  LIKE  THIS  WOULD  WORK  FOR  ABOUT  ANY  CASE) 


P  COMMENT  (LET'S  TRY  ANOTHER  CASE) 


p 

HANDCHECK 

(  LOW 

= 

0, 

HIGH 
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19  , 
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10  . 
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10  . 
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LOWER 

THAN 

2) 

p 

HANDCHECK 
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1  ) 

p 

HANDCHECK 

(  LOW 
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0, 

HIGH 
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1, 

MID 

= 

0  . 

TRY 

0. 

FOUND 

IT  ) 

P  COMMENT  (HOW  WOULD  WE  KNOW  THAT  WE'RE  DONE  THEN?) 

P  COMMENT  (WHEN  HIGH  =  LOW.  I  THINK  THAT’S  GONNA  WORK) 

TIME  1:10:00  -  TASK  13 

P  COMMENT  (IF  LOWER  THAN  0,  THEN  HIGH=0.  THEN  DOES  HIGH  =  LOW?  YES) 

P  COMMENT  (THEN  IT  WASN'T  FOUND) 

PV  DECLARE  (INTEGERS,  LOW,  MID,  AND  HIGH) 

S  int  low , mid , high , i , index  =  0, 

S  mod , di v , sum=0  , 

S  nuns [20]  =  (1,3,5,8,9,12,13,19,25,26,27,29,33,35,38,39,40,43,45,50); 

PV  INSERT  (WHILE  LOOP) 

S  while(  (low  !=  high)  a  (nums(mid)  !=  x ) )  { 

PV  GOTO  (ABOVE  WHILE  LOOP) 

PV  INITIALIZE  (LOW  AND  HIGH) 

S  low  =  0; 

S  high  =  19; 

PV  CALCULATE  (FIRST  MID) 

S  mid  =  (high  +  low)/2; 

PV  GOTO  (INSIDE  WHILE  LOOP) 

PV  INSERT  (IF  STATEMENT  TO  RESET  LOW) 

PV  INSERT  (ELSE  CLAUSE  TO  RESET  HIGH) 

S  i f  ( i  >  nums ( mid )  ) 

S  1  o  w  =  m  i  d ; 

S  els* 

S  high  =  mid; 

PV  CALCULATE  (MID) 

S  mid  =  (high  +  1  o  w  )  /  2  ; 

P  NEED  (PRINT  STATEMENT  TO  TELL  ME  WHAT'S  GOING  ON) 

PV  GOTO  (BEGINNING  OF  WHILE  LOOP) 

PV  PRINT  (LOW,  MID,  HIGH) 

S  printf ( "\nlo«  =  %d;  mid  =  %d;  high  =  %d", low, mid, high); 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  ERROR  (UNEXPECTED  "  >  "  IGNOREDI 
P  COMMENT  (STILL  HAVE  MISMATCHED  PARENTHESES) 

PV  RUN  (PROG) 

PV  TEST  (13.  LOW,  MID,  HIGH  ARE  0,  9,  19.  THEN  0,  4,  9) 

PV  COMMENT  (  SOMETHING’S  WRONG.  LET  ME  TRY  A  DIFFERENT  NUMBER) 

PV  TEST  (0,  WENT  TO  0,9,19,  THEN  0,4,9,  THEN  0,2,4,  THEN  0,1,2, 

THEN  0,0,1) 

PV  TEST  (THE  HIGHEST,  50.  INFINITE  LOOP  AT  18,18,19) 

PV  EDIT  (PROG.C) 

PV  INSERT  (IF  NUMS [MID]  =  I) 
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PV  NEED  (TO  PRINT  OUT  RESULTS) 

TIME  1:20:00  -  TASK  #3 


PV  GOTO  (AFTER  WHILE  LOOP) 

PV  INSERT  (IF  STATEMENT  TO  CHECK  IF  NUMBER  FOUND) 

PV  PRINT  (FOUND  MESSAGE,  I  ,  AND  MID) 

S  if  (numblmid]  «=■  i) 

S  printf (  "\nlnput  number,  %d,  found  at  array  index  %d . \n " , i , mid ) ; 


PV  INSERT  (ELSE  CLAUSE,  FOR  NOT  FOUND  CASE) 

PV  PRINT  (NOT  FOUND  MESSAGE) 

S  else 

S  printf ( "\nlnput  number,  %d,  does  not  exist  in  the  array. \n"); 


P  COMMENT  (ACTUALLY  THE  WAY  I  WAS  FIGURING  IT  OUT  IT  WOULD  BE  +1) 
PV  CHANGE  (ADD  ONE  TO  MID  INITIALIZATION) 

S  mid  =  (high  +  low  +  l)/2; 

P  COMMENT  (LET  ME  DOUBLE  CHECK  MY  VALUES) 

P  HANDCHECK  (FOR  0,  WE  WOULD  GET  9.  HIGH  =  9.  LOW  =  4) 

P  HANDCHECK  (LOOK  AT  4  AND  WE  GET  2.  AND  THEN  WE  GET  1) 

P  COMMENT  (NOW  IT'S  BETWEEN  0  AND  1.  THAT  WOULDN'T  WORK...) 


P  HANDCHECK  (IF  MID  WAS  1  AND  IT  WAS  STILL  LOWER  THAT,  BECAME  1  NOW) 
P  HANDCHECK  (FIND  OUR  MID.  (HIGH  +  LOW)/2) 

P  COMMENT  (DOESN'T  WORK  ON  THAT  SIDE.  BUT  THE  OTHER  WAY  IT  DOES) 


P  HANDCHECK  (THAT  WOULD  BE  10.  11  GIVES  US  5.  5+1  GIVES  US  3) 

P  HANDCHECK  (THAT  GOES  3,  THAT  GOES  2,  AND  THAT  GOES  TO  1) 

P  COMMENT  (JUST  1  AGAIN.  EVIDENTLY  STUCK  IN  A  LOOP) 

PV  CHANGE  (REMOVE  PLUS  ONE  FROM  MID  INITIALIZATION) 

S  mid  *  (high  +  low)/2; 

P  COMMENT  (I  HAVE  TO  FIGURE  OUT  SOME  SORT  OF  COMPARISON) 

P  COMMENT  (RUN  IT  AND  LOOK  AT  THIS  OUTPUT  SO  I  CAN  FIGURE  IT  OUT) 

PV  EXIT  (PROG.C) 


PV  COMPILE  (PROG.C) 

PV  ERROR  (UNEXPECTED  " ) "  IGNORED) 

PV  ERROR  (NUMB  NOT  DECLARED  WITHIN  SCOPE  OF  THIS  USAGE) 
P  COMMENT  (I  MADE  A  MISTAKE  -  TYPO) 

PV  EDIT  (PROG.C) 

PV  CHANGE  (NUMB  TO  NUMS  ) 

S  if  ( nums [ mi d ]  »»  i) 


PV  COMMENT  (FORGOT  TO  PUT  THE  INDEX  ON  THE  END  OF  THIS  PRINT) 

PV  CHANGE  (ADD  "I"  TO  NOT  FOUND  MESSAGE) 

S  printf ( "\nlnput  number,  %d,  does  not  exist  in  the  array  .\n" , i ) ; 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

P  COMMENT  (BUT  I  HAVEN'T  FIGURED  OUT  HOW  TO  GET  RID  OF  THIS  BUG) 

PV  ERROR  (UNEXPECTED  ">"  IGNORED) 

PV  RUN  (PROG) 

PV  TEST  (1,  FOUND  AT  INDEX  0) 

PV  TEST  (50,  INFINITE  LOOP) 

PV  TEST  (45,  FOUND  AT  INDEX  18) 

PV  TYPEFILE  (PROG.C,  TO  SEE  WHAT  THE  NUMBERS  ARE) 

PV  TEST  (29,  FOUND  AT  INDEX  11) 

PV  TEST  (ALL  NUMBERS  IN  THE  ARRAY) 

PV  TEST  (50,  INFINITE  LOOP  WITH  18,18,19) 

P  COMMENT  (TRY  SOME  THAT  AREN'T  THERE) 

PV  TEST  (44,  INFINITE  LOOP  WITH  17,17,18) 

PV  TEST  (2,  INFINITE  LOOP  WITH  0,0,1) 

TIME  1:30:00  -  TASK  #3 


PV  EDIT  (PROG.C) 

PV  CHANGE  (TAKE  OUT  EXTRA  CLOSING  PARENTHESIS) 

S  if  (  (fp  -  f open ( " f i le . out " , "w"  )  )  ««  -1}  ( 


PV  CHANGE  (INITIALIZATION  OF  MID,  FROM  10  TO  20) 
S  mid  »  high; 
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PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

PV  TEST  (0,  DOES  NOT  EXIST) 

PV  TEST  ( 1 ,  FOUND  AT  0 ) 

PV  TEST  (50,  FOUND  AT  19) 

PV  TEST  (46,  INFINITE  LOOP  WITH  18,18,19) 

P  COMMENT  (ITS  STUCK  IN  A  LOOP  WITH  LOW  =  MID) 

PV  EDIT  (PROG.C) 

PV  CHANGE  (WHILE  CONDITION  FROM  LOW  !=  HIGH) 

S  while(  (low  is  mid)  &&  (nums[mid]  is  i))  { 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

PV  TEST  (46,  DOES  NOT  EXIST) 

PV  TEST  (1,  FOUND  AT  0) 

PV  TEST  (0,  DOES  NOT  EXIST) 

PV  TEST  (44,  DOES  NOT  EXIST) 

PV  TEST  ( 2 ,  FOUND  AT  2 ) 

PV  EDIT  (PROG.C) 

PV  CHANGE  (COMMENT  OUT  DEBUG  PRINT  STATEMENT) 

S  /*  printf("\nlow  =  %d;  mid  =  %d;  high  s  %d", low, mid, high);  */ 

PV  DELETE  (COMMENT  BRACKETS  AROUND  FIRST  TWO  TASKS) 

PV  EXIT  (PROG.C) 

PV  COMPILE  (PROG.C) 

PV  RUN  (PROG) 

PV  TEST  (46,  DOES  NOT  EXIST) 

PV  TYPEFILE  (FILE. OUT) 

P  COMMENT  (LOOKS  GOOD) 
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((include  <stdio.h> 


*ain|  ) 

/*  This  program  initializes  array  of  integers.  */ 


FILE  *  f  p ; 

int  low , mid , high , i , index  =  0, 
mod , di v , sum=0  , 

nuns [ 20  J  =  (1,3,5,8,9,12,13,19,25,26,27,29,33,35,38,39,40,43,45,50) 
char  strilO],  tmp[3); 

printf  ("The  NUMS  array  has  been  initialised."); 

if  (  (  fp  *  f open (" fi 1 e . out  ", "w  "  )  )  ==  -1)  { 

perror ( "fopen"  )  ; 
e  x  i  t  (  - 1  )  ; 

} 

printf ( "\n\nPlease  enter  a  number  between  1  and  50:"); 
get  s ( s  t  r ) ; 

sscanf (str , "14" , Vi )  ; 
low  «  0 ; 
high  =  19; 
mid  =  high; 

while!  (low  !  =  mid)  it  (nums(mid)  !«  i  )  )  { 

/*  pr int f ( "\nlow  =  %d;  mid  =  %d;  high  =  %d" , 1 ow , mi d , high ) ;  */ 

if  ( i  >  nuns ( mid  )  ) 

low  =  mid ; 
else 

high  =  mid; 
mid  =  (high  +  1  o  w  )  /  2  ; 

} 

i  f  (  nums  (  mid  ]  =«■  i  ) 

printf ( "\nlnput  number,  td,  found  at  array  index  %d . \n " , i , mi d  )  ; 

else 

pr int f ( "\nlnput  number,  %d,  does  not  exist  in  the  a r ray . \n  "  ,  i  )  ; 

for ( i  =  0 ; i <  20 ; i  +  + ) 
sum  +=  nums (ij; 

f pr int f ( f p , "\n\n\nThe  sum  of  all  the  numbers  is:  *d.\n\n\n“,sum); 
f pr int f ( f p , " Ar r ay  Derimal  Octal\n"); 

f print f ( fp Index  Rep  Rep\n\n"); 

for  ( i  =  0 ;  i <  2  0  ;  i  +  +)  { 

strlO]  =  ' \ 0  '  ; 
di v  =  nums [ i  )  ; 
while  (div  >  0)  ( 

mod  =  div%8; 
sprintfltmp, "%d" , mod ) ; 
strcat(tmp.str); 
s  t  rcpy ( s  t  r , tmp ) ; 
div  /=  8; 

) 

fprintf(fp,”  %2d  %2d  % s\n " , i , nums ( i  )  , s t r  )  ; 

) 

t 
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